Great video, very clear! A suggestion for the future, what do you guys think about creating a nice infographic with high resolution for the future to use in explanations?
I have a small doubt, prior to 1.3 the client used to generate the Pre Master Key and encrypt it with servers public key, as per your demonstration Client is sending Key share before even getting the Public key, does it mean that client already gets the public key from the repository and encrypts it and send ? Thank you in advance :)
Hi Jubair...great question! Prior to TLS 1.3, the client and server could use the RSA algorithm to exchange keys. In RSA, the client uses the server's public key to encrypt the pre-master secret as you mentioned. However, in TLS 1.3, RSA is not allowed to be used for key exchange. In TLS 1.3, the Diffie Hellman key exchange is used to exchange keys. The Diffie Hellman key exchange requires that both the client and server generate their own random integer values and then send other calculated values to each other that are based on their own secret values. So, the "key share" referenced here is the client's calculated value that it sends to the server. It can send this without ever receiving anything from the server. Here's a video I did on the Diffie Hellman key exchange: czcams.com/video/pa4osob1XOk/video.html And, here's one on Perfect Forward Secrecy: czcams.com/video/IkM3R-KDu44/video.html I hope this helps!
@@devcentral Wow, thank you very much for the reply, I am new to F5 and learning, let me know if there are documents I can get to be a skilled F5 admin, thanks a ton again 😊
Great question Adarsh! As you noted, the encryption in TLS 1.2 and earlier is asymmetric (for sharing keys) followed by symmetric (for bulk encryption). In TLS 1.3 the same thing happens. The keys are shared via asymmetric encryption (in fact, it's mandatory in TLS 1.3 that the client and server use Perfect Forward Secret ciphers for key exchange) but then the bulk encryption is done using symmetric encryption. I hope this helps!
I seen Diffie Hellman been used with RSA for assymetric part in tls 1.2. If it's not the case in 1.3, then there might be successful man in the middle attack?
Hi Nur...great question! The server's public key (which is included in the larger certificate) is still used for authentication purposes...typically using RSA for authentication. But, TLS 1.3 uses only Perfect Forward Secret ciphers for key exchange...so the key exchange algorithms are all Diffie Hellman. Diffie Hellman doesn't use the server's public/private keys for key exchange. So, the server's keys are still used for authenticating the server to the browser (i.e. is this the correct server to be connecting), but the server's keys are not used for key exchange with TLS 1.3. I hope this helps!
sir what about version negotiation happen between client TLS and server TLS i mean if client has new version like 1.2 and server has 1.3 or vice versa then connection established or not? please make a shot video on that.
ultimately, the server gets to make the final call on the cipher suite, version, etc. the server (and/or client) can be configured to use multiple versions of TLS (1.1, 1.2, 1.3). If, for example, the client is trying to talk via TLS 1.3 and the server can only talk TLS 1.2, then the client (if configured) would back down to TLS 1.2 and the connection would be established using TLS 1.2. If the client was only configured to talk TLS 1.3 and the server was only configured to talk TLS 1.2 (or vice versa), then the connection would terminate because they couldn't both find a version that they are both configured to talk with. Hope this helps!
Hi...great question! The idea with keyshare is that the Client and Server both have to provide information to one another in order to calculate the symmetric key that will be used for bulk encryption. The TLS handshake is the process that (among other things) shares the information between Client and Server so that they can each independently calculate the symmetric key used for the bulk encryption. During this process, each of the Client and Server contributes their "share" of information needed to ultimately generate the symmetric key. As for the exact information needed from each side, it depends on the exact cipher suite choses for key exchange and bulk encryption. For example, if a Diffie-Hellman key exchange is chosen, each side will need to contribute their portion of the Diffie-Hellman calculations so that they can independently calculate the shared key for bulk encryption. They can't calculate the shared symmetric key until they have the key exchange information from the other party (Client/Server). In TLS 1.3, the handshake process speeds up significantly because the Client preemptively guesses the cipher suite that the Server will choose. The server still has the final say on which cipher suite is chosen, but many times the Client can guess the correct cipher suite before the Server confirms the chosen suite. Because of this, the Client can go ahead and send what would be the key exchange information for the chosen cipher suite when it initially sends the "Hello". Then, the Server can calculate the shared symmetric key and go ahead and start encrypting data very early in the handshake process. I hope this helps!
90% stuff not needed/related....Cummon...Get into the details of 1.3..This I felt like scratching the surface.Remember sitting in an interview and talking like this..I dont think even F5 will hire you if you talk exactly the guy in the video explained...This is so useless stuff I felt like...
Great video, very clear! A suggestion for the future, what do you guys think about creating a nice infographic with high resolution for the future to use in explanations?
Excellent videos!
Glad you enjoyed it!
Great video. Well explained.
glad you enjoyed it!
I have a small doubt, prior to 1.3 the client used to generate the Pre Master Key and encrypt it with servers public key, as per your demonstration Client is sending Key share before even getting the Public key, does it mean that client already gets the public key from the repository and encrypts it and send ?
Thank you in advance :)
Hi Jubair...great question! Prior to TLS 1.3, the client and server could use the RSA algorithm to exchange keys. In RSA, the client uses the server's public key to encrypt the pre-master secret as you mentioned. However, in TLS 1.3, RSA is not allowed to be used for key exchange. In TLS 1.3, the Diffie Hellman key exchange is used to exchange keys. The Diffie Hellman key exchange requires that both the client and server generate their own random integer values and then send other calculated values to each other that are based on their own secret values. So, the "key share" referenced here is the client's calculated value that it sends to the server. It can send this without ever receiving anything from the server.
Here's a video I did on the Diffie Hellman key exchange: czcams.com/video/pa4osob1XOk/video.html
And, here's one on Perfect Forward Secrecy: czcams.com/video/IkM3R-KDu44/video.html
I hope this helps!
@@devcentral Wow, thank you very much for the reply, I am new to F5 and learning, let me know if there are documents I can get to be a skilled F5 admin, thanks a ton again 😊
But TLS 1.2 could also use ECDH for key exchange, so ?
Amazing work.
A packet capture of the handshake showed also be shown and/or made available to be downloaded.
in TLs 1.2 or previous, the encryption was Assymetric, followed by symetric. How is it happening in 1.3?
Great question Adarsh! As you noted, the encryption in TLS 1.2 and earlier is asymmetric (for sharing keys) followed by symmetric (for bulk encryption). In TLS 1.3 the same thing happens. The keys are shared via asymmetric encryption (in fact, it's mandatory in TLS 1.3 that the client and server use Perfect Forward Secret ciphers for key exchange) but then the bulk encryption is done using symmetric encryption. I hope this helps!
▶️
Thanks for explaining it
glad you enjoyed it!
I seen Diffie Hellman been used with RSA for assymetric part in tls 1.2. If it's not the case in 1.3, then there might be successful man in the middle attack?
very clear thank you
Glad you liked it and thanks for the comment!
1. the tcp handshake still occurs
2. certificate verification also happens
Hi. So in TLS 1.3, does it mean the server's public key no longer plays a role in the whole encryption process?
i think he meant public key when he said certificate from server
Hi Nur...great question! The server's public key (which is included in the larger certificate) is still used for authentication purposes...typically using RSA for authentication. But, TLS 1.3 uses only Perfect Forward Secret ciphers for key exchange...so the key exchange algorithms are all Diffie Hellman. Diffie Hellman doesn't use the server's public/private keys for key exchange.
So, the server's keys are still used for authenticating the server to the browser (i.e. is this the correct server to be connecting), but the server's keys are not used for key exchange with TLS 1.3. I hope this helps!
@@devcentral how does this prevent man in the middle attack?
sir what about version negotiation happen between client TLS and server TLS i mean if client has new version like 1.2 and server has 1.3 or vice versa then connection established or not? please make a shot video on that.
ultimately, the server gets to make the final call on the cipher suite, version, etc. the server (and/or client) can be configured to use multiple versions of TLS (1.1, 1.2, 1.3). If, for example, the client is trying to talk via TLS 1.3 and the server can only talk TLS 1.2, then the client (if configured) would back down to TLS 1.2 and the connection would be established using TLS 1.2. If the client was only configured to talk TLS 1.3 and the server was only configured to talk TLS 1.2 (or vice versa), then the connection would terminate because they couldn't both find a version that they are both configured to talk with. Hope this helps!
Thank you, great explanation!
glad you enjoyed it!
Would you say Diffie-Hellman is the most common key exchange algorithm used for TLS 1.3 connections?
yes, definitely. in fact, it's extremely common among TLS 1.2 connections as well. thanks!
What is the keyshare ypu are talking about? Please explain it in detail....
Hi...great question! The idea with keyshare is that the Client and Server both have to provide information to one another in order to calculate the symmetric key that will be used for bulk encryption. The TLS handshake is the process that (among other things) shares the information between Client and Server so that they can each independently calculate the symmetric key used for the bulk encryption.
During this process, each of the Client and Server contributes their "share" of information needed to ultimately generate the symmetric key. As for the exact information needed from each side, it depends on the exact cipher suite choses for key exchange and bulk encryption. For example, if a Diffie-Hellman key exchange is chosen, each side will need to contribute their portion of the Diffie-Hellman calculations so that they can independently calculate the shared key for bulk encryption. They can't calculate the shared symmetric key until they have the key exchange information from the other party (Client/Server).
In TLS 1.3, the handshake process speeds up significantly because the Client preemptively guesses the cipher suite that the Server will choose. The server still has the final say on which cipher suite is chosen, but many times the Client can guess the correct cipher suite before the Server confirms the chosen suite. Because of this, the Client can go ahead and send what would be the key exchange information for the chosen cipher suite when it initially sends the "Hello". Then, the Server can calculate the shared symmetric key and go ahead and start encrypting data very early in the handshake process.
I hope this helps!
Well explained
glad you enjoyed it!
where person is writing ? is this on a glass? how is this annotation works can anyone explain it to me?
czcams.com/video/wNnsU1e8uoM/video.html
@@adithyavaishnav4081 thanks man
How does he write mirrored so perfect? 😳
czcams.com/video/U7E_L4wCPTc/video.html
the trick is he write normally but in post production they mirror the image so from our perspective text is normal
amazing the way he writes backwards the entire video
you can see how we create these here! czcams.com/video/U7E_L4wCPTc/video.html
At the start of the video: "Now I'm gonna learn more about TLS".
A few seconds later "But first I'm gonna learn how he writes backwards!"
90% stuff not needed/related....Cummon...Get into the details of 1.3..This I felt like scratching the surface.Remember sitting in an interview and talking like this..I dont think even F5 will hire you if you talk exactly the guy in the video explained...This is so useless stuff I felt like...