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: kzfaq.info/get/bejne/psdkotagx5e8f58.html And, here's one on Perfect Forward Secrecy: kzfaq.info/get/bejne/f9F9ZrVesKrZZGg.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 ?

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 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?

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!

glad you enjoyed it!

glad you enjoyed it!

Glad you enjoyed it!

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!

Glad you liked it and thanks for the comment!

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!

glad you enjoyed it!

kzfaq.info/get/bejne/rbSeprhiyp7Zn4E.html

@@adithyavaishnav4081 thanks man

kzfaq.info/get/bejne/i511kq9l3Km0hJc.html

the trick is he write normally but in post production they mirror the image so from our perspective text is normal

you can see how we create these here! kzfaq.info/get/bejne/i511kq9l3Km0hJc.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!"