CLIENT: - Browser wants to establish connection to a server. - Client sends Hello’ message - TLS protocol number (1.2,1.3) - Cipher suite client supports SERVER: - Server sends ‘Hello’ message - Server sends certificate file - Includes server’s public key - Server sends ‘Hello done’ message CLIENT: - Client checks that certificate file - Checks if it has been revoked - Checks if it is still valid - Client generates ‘Pre-Master Secret Key’ (PMSK) - Client pulls some characters from server’s public key, encrypts that with server’s public key, and creates Pre-Master Secret Key - Based on PMSK, it will generate SYMMETRIC KEY from that PMSK that will be used for bulk encryption. - Client sends ‘Client finished’ message SERVER: - Server decrypts PMSK with his private key - Server creates SYMMETRIC KEY by decrypting PMSK. This symmetric key will be same as client’s symmetric key because it was encrypted with PMSK. - Server sends ‘Change Cipher Spec’ message. This tells client to change from asymmetric to symmetric key exchange - Server sends ‘Finished’ message END: Both of them have symmetric key used.
Video is mirror image flipped, and the tshirt he's wearing has the text printed also mirror image flipped. That's how he's able on the glass so well. Now start learning some TLS!
Thanks. Thought that was going on but I was so distracted considering what if he was just so good writing backwards, that I had to rewatch halfway to pay attention.
Thank you for helping me better understand this. I'm studying for my cert and I kinda understood reading it but this makes more sense! Awesome video and explanation.
Its really amazing explanation on TLS handshake Thank you ... Just for my curiosity which application you used to record video with screen whiteboard option.
Thanks and that was great video. Have one question in the actual data transfer , the data is encrypted with symmetric encryption and the symmetric key is encrypted with asymmetric encryption for each session?
Thanks for the comment satksd! The whole point of the asymmetric encryption is to share the encryption keys for the symmetric encryption. So, for a given session, the client and server will begin by using asymmetric encryption to share the keys that they will both use for the symmetric encryption. The symmetric encryption is used for encrypting all the data that is sent between the client and server during that session. So, once the symmetric encryption keys are exchanged (via the asymmetric encryption), then the asymmetric encryption is not needed any more until a new session is established and new keys need to be exchanged.
Thanks for the great question! In this particular example, the key exchange is RSA. So, you wouldn't see Diffie Hellman in this specific example. Here's a video of how Diffie Hellman would be used: ruclips.net/video/pa4osob1XOk/видео.html
Thanks! Pretty good explanation of how the TSL handshake works. Got a question around how the symmetric key is generated. So based on the video looks like, we create that pre-master secret from contents from the certificate that the server shared plus a key that client generates using some tools/security suite on the fly. Client then encrypts it using the public key that server shared in the certificate. Then client send it to the server. Server then decrypts it with the private key. The resultant decrypted content would then content the shared encryption key. Is my understanding right? Is there a security suite that needs to be present in the client to create such shared key? So shared encryption key generation is the responsibility of the client, correct?
Hi Sailesh...great question! When the client initially contacts the server to initiate the secure connection (CLIENT HELLO for TLS), the client sends a list of cipher suites that are available for use on the client browser. In that cipher suite is a list of possible symmetric encryption algorithms that could be used (most of the time, the symmetric encryption type is AES). When the server gets the list of cipher suites from the client, the server checks to see if any of the cipher suites match what the server is willing to use (the server has a pre-loaded list of cipher suites that are configured for that specific server). The server picks the cipher suite that best matches its list of cipher suites (at least one has to match or else the connection gets terminated). Then, when the cipher suite is established, it tells the client and server exactly what kind of encryption methods will be used for that session. For example, Diffie Hellman could be used for key exchange while AES is used for symmetric encryption. So really, both the client and the server are involved in the creation of the symmetric encryption key, but the server is the one that gets to drive the choices (with picking the cipher suite and also sending its public key for initial encryption). I hope this helps!
@@devcentral I feel that things are lot clearer now about the symmetric key mechanism now that I have gone through few of the videos and the comment from you guys here. Agree that both server and clients are involved. But, someone still has to create the shared key that both the party agree to use. Are they generated on the fly? Am I missing something?
@@devcentral Thanks for sharing. I had already seen that video which gave much better understanding about shared encryption. But, even going through them things were not clear how shared encryption key gets generated.
Great question! The math behind these calculations can get pretty tricky, but here's a link to some good info on the key generation topic: stackoverflow.com/questions/3936071/how-does-browser-generate-symmetric-key-during-ssl-handshake
Great Video..!! One quick question.. How does the client verify that the (certificate and the public key) is coming from Big-IP not from an anonymous attacker?
Great question! The certificate is signed by the Certificate Authority (CA) so the client can use that signature as the validation that the certificate is from the proper sender. The server typically sends a Certificate Signing Request (CSR) to the CA to get a signed certificate for the server. Then, the server can send that signed certificate to the client so that the client knows it has been signed by the CA.
Would be great to know the reason why the client does not send the calculated primary key right away to the server instead of the pre-master secret/key? Only the server can decrypt that message anyway ...
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
cool presentation. Questions: is the pre-master key actually exchanged, if so, what if man in the middle learned it, can it be used to create the eventual asymmetric key? Meaning during the TLS handshake is there vulnerability? 2nd question, is the final symmetric key ever exchanged? thanks.
The pre master secret is shared but encrypted with the public key of the server (found in the server certificate). That way even if someone can tap into the message they cannot decrypt it unless they know the servers private key.
Awesome explanation. But I didn't get the difference between Pre-master secret and symmetric key. As per my understanding they are different names to the same key. Could someone please correct me?
Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
glad you enjoyed it! bulk encryption (and thereby, bulk data) is the data transmitted between client and server after the key exchange takes place. This is, by far, the most data transmitted between client and server. The key exchange is simply there to exchange the keys that will be used in the symmetric (bulk) encryption.
im a little confused... wouldn't it suffice if only one side generated a symmetric key? why is it necessary that even though it's the same symmetric key in a way another one would be generated by the web server?
Great question! In order for the cryptography to work, one side must encrypt the data and then the other side must be able to decrypt the data so they can read it. The way symmetric cryptography works is that the same key (same value) does both the encrypting and decrypting. So, if only one side had the key, then they would be able to encrypt the data, but the other side wouldn't be able to decrypt it. So, both sides need to compute the exact same symmetric key so that they can each use that key to encrypt/decrypt. I hope this helps!
@@devcentral I know but rather than both the sender and receiver having 1 key as I thought before they will both compute the same key (individually) to use to encrypt & decrypt data
Does symmetric key encryption used on top of the asymmetrical encryption, or do both nodes switch over to symmetric encryption? If so, why not asymmetrical to host and symmetric back to client?
Hi Christopher...great questions! The asymmetric encryption is used at the beginning of the handshake and the primary purpose of this is to share/create the keys that will be used in the symmetric encryption. Both sides start with asymmetric and then (once the symmetric keys have been created and verified), they both move to symmetric encryption for the duration of the session. I hope this helps!
Great question, Mike! The random numbers are used to calculate the symmetric key used for the bulk encryption algorithm. I did a video on how the RSA algorithm works here: ruclips.net/video/rVQpK6NcYIE/видео.html and I also did one on how the Diffie-Hellman algorithm works here: ruclips.net/video/pa4osob1XOk/видео.html I hope this helps!
very good video thanks for sharing, one question, what is the encryption algorithm used to exchange communication between client and server ? is it AES ? thanks
Hi Diego...great question! The encryption algorithm used to exchange communication between client and server is negotiated in the initial part of the TLS handshake. That said, AES is almost always used in modern web applications today. I hope this helps!
@@devcentral Thanks for the reply ! another question... if you proceed to a site which is not using a valid certificate and then you get the warning and click on "proceed to unsafe" does the ssl handshake still happen ? if so, does encryption happen even if the certificate could not be validated ? Thanks
@@diegoramos27 great question! yes, even if the certificate is not valid, the TLS handshake should still complete (although it's possible to configure to drop the connection if the certificate is invalid). In this case, the client and server would still have an encrypted connection, but the client just wouldn't know for sure that the web server is the correct one.
No, Akash... Diffie Hellam does NOT have to be used. Remember, the client sends over the *Pre-shared master key.* Okay... so what's that exactly? Well... its basically the *recipe* for the "symmetric key." However, the client does NOT send the "recipe" in *clear text.* Instead, the client ENCRYPTS the recipe using the Server's Public Key (aka, the certificate)... and THEN its sends it to the server. :]
Hi Chilly Vanilly...great question! The client is not required to provide its certificate unless the server is configured to require client authentication. Then, the client would need to present a valid certificate to prove who they are in order for the handshake to complete. Thanks!
@@chillyvanilly6352 Cliennt's usually provide a username/password to CONFIRM who they are. Thats the reason you are able to "LOG IN" in order to read your email. :]
What's stopping a hacker from using the symmetric key on the client side to communicate with server after it's generated? Does that question even make sense?
Great question!! If an attacker were to get the symmetric key from the client, he could definitely decrypt all communication between client and server. This is why it is so important to secure the symmetric key. This is also one of the reasons many clients and servers are moving to "Perfect Forward Secret" ciphers so that the symmetric key changes with every new session. Here's more info on Perfect Forward Secrecy in case you are interested: ruclips.net/video/IkM3R-KDu44/видео.html Hope this helps!
Great question Mahendra! It all depends on how you configure, in this case, the server. If the client is using TLS 1.0 and the server is set to use TLS 1.2, then you can configure the server to abort the TLS handshake when it realizes the client can't use TLS 1.2. Or, you can configure the server to allow a downgrade to TLS 1.0 when it realizes that the client can only use TLS 1.0. So, it depends on how you configure the client cipher suite. I hope this helps!
@@devcentral Thanks John for your reply. Glad to hear from you. Much appreciated, if you can explain along with sample client/server communication example.
beginner question here... why not just the client generate the symmetric key, encrypt it with the public key, send it to the server. The server decrypts the message with its private key to obtain the shared symmetric key?
Jason, the client needs to verify that the server is who they say they are before sending it’s own key, hence it first negotiates with the server to get the servers public certificate. Once the client has the certificate and public key it checks with a certificate authority (third party check which is briefly mentioned, but not drawn in the video) to verify the server is who the client expects it to be, only then will the client start negotiating symmetric keys.
@Jeggle Publishing Thank you for taking the time. I understand the initial authentication handshake but I appreciate you not making that assumption. My question pertains to what happens after, the necessity of the simultaneous calculation on both sides with the premaster as input to arrive at the symmetric encryption key. Could the client just have come up with this symmetric key, encrypt with the server's public key, send it. both sides acknowledge to use the symmetric key from then on?
@@jasonb3200 LOL Honestly... what you proposed... is basically what happens anyway. LOL You're saying that, after the client CONFIRMS that the server is REALLY who it claims to be.... "WHy doesn't the client just SEND the symmetric key directly?" But.. it doesn't. instead, it sends the *Pre-shared master key.* Okay... so.... what exactly is that about? Well... its basically the *recipe* "for" the symmetric key. It's the equivalent to "ME" needing to send "YOU" my grandma *special* German Chocolate cake. i have the ingredients... i have the Oven... and i have the recipe.... so i could put in the *TIME & EFFORT* to "bake the cake" and then send it to you. Or, at the end of the day... i know that: You already have the Ingredients, You already have an Oven.... So... it's actually easier if i just *SEND you my grandma's RECIPE...* and then you can BAKE the cake yourself. At the end of the day.... think about it this way: which is EASIER to send to someone: a) a German Chocolate Cake, or b) the *recipe* for a German Chocolate cake. ? The key exchange probably follows the *same* reasoning. :]
So, we can get 1 symmetric key (ONLY) out of Pre Master Secret ? The reason I ask, if both server and client are able to generate 1 symmetric key out of 1 PMS, I would think the answer is 1.
Hi...great question! The purpose of the Pre Master Secret is to ultimately create a shared symmetric key that the client and server can both use for the duration of that particular session. When the session is over (or renegotiated, etc), then the client and server will generate a new symmetric key for the new session. There would only need to be one pre master secret used to generate the shared symmetric key for a given session. But, like I mentioned, this entire process would happen again for any new sessions between the client and server (or a different client and the server). I hope this helps!
Thanks & really appreciate your work . I have one question here : at 7:51, should Change Cipher Spec be sent before Client Key Exchange or after that ? I think Change Cipher Spec should be the last one sent in plaintext (accroding to RFC5246) , but not sure if we must encrypt Client Key Exchange before sending it out.
As far as i know there's nonce in the handshake process. I know it's used to prevent some replay attack but I wonder if nonce is used to create pre master secret. Or Is pms only genereated from server's public key?
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
I got everything but I have a single doubt. Pre master secret is derived from public key. And then it is encrypted and shared with the server. And then server has the same pre master key. And now both client and server makes a symmetric key. How? What kinds of algo do they use? And how do they ensure that they make the same symmetric key?
And how are these public keys and private keys decided by the server before sending to client? During the deployed of the application? Do the developer provide public and private keys?
Great question! The "change cipher spec" message essentially alerts the other side that it's time to move to symmetric encryption. Plus, all future messages after that are encrypted using the symmetric key instead of the public/private key pair. Thanks!
@@siddharthmanumusic once the client and server establish the shared symmetric key, they use that key for encryption/decryption for the duration of that specific user session. Sessions typically last for as long as the client has the browser open to that specific page (or pages) or until there is no more client activity (like, when you visit a banking page and then don't take any action, they will sometimes ask if you are still there or want to extend the session). Thanks!
Thanks for the video. One question I have. You mentioned that when server sends its certificate to the client, it also sends its public key. In this case, any MITM attacker can replace this certificate with its self-generated certificate signed using his private key and send to the client with his public key. So, client will have no way to identify if the cert+public key it received is from the actual server or from the attacker. Is my understanding correct?
Hi Harshit...great question! You are exactly right that a MITM could step in and send a self-generated certificate signed by his own private key. The issue, though, is that the MITM will have to get someone/something to sign the certificate. The easy answer is for the attacker to sign the certificate himself, but all modern browsers will notice that a certificate has been "self-signed" and will prompt a warning page to the user saying that the page you are attempting to view has a certificate that has been self-signed. The idea is that the Certificate Authority has to sign the certificate in order to avoid the browser warning page. And, a Certificate Authority is not going to issue/sign a certificate for a secure website that already has a valid certificate. The Certificate Authority is supposed to check these things before they ever issue a certificate and public/private key for a given website. Here's a quick article that I found that goes into a bit more detail: www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/ I hope this helps!
@@devcentral But this in turn requires the Certificate Authorities to exists, so we're back to square one, because this requires trusting the Authorities :P And they can be the biggest Men In The Middle here, because of the scale of their power and lack of suspicion from the clients :q Imagine someone hacks the CA and swaps the keys to their own (happened already). Why do we need CAs anyway? Can't we do a two-sided key exchange without them? :q I see this entire CA thing as another huge pyramid scheme to squeeze money from people for selling certificates to them :q
Bon Bon The answer is not correct. What he's omitted is that the CertificateVerify message which is sent after the Certificate message contains a digital signature signed by the private key, and that can be verified by its public key. So only the owner of that public key can create a valid CertificateVerify message.
EJP is correct .. Every browsers have CA root bundles installed which has the public key of trusted CA's who able to verfiry the sigature in certifcate which signed using their(CA) own private key at the time of CSR.. So any MITM hacked and replaced the certificate ,signature cannot be verified by browser and I think you will see warning message or connection may be dropped..
As far as I can understand, the first 4 steps(until hello done from big ip) are not encrypted . Or the first hello from client also includes its public key. I am confused. Please explain.
client never send its public key to server, client only use server's public key to encrypt message, while server can decrypt the message coming from client with its private key. after decryption, server knows the suggested pre-master-secret from client, then use its private key to encrypt pre-master-secret to create a symmetric key, send it back to client, client can decrypt this symmetric key by servers public key, if client get the original pre-master-secret, then it proves client is talking to the intented server, because by now no 3rd party knows this newly created symmetric key, for later communications client can use this symmetric key to encrypt, and server can use the same symmetric key for decryption.
Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
I have a doubt, Since you said Pre-master secret is generated from the public key that means the logic to derive the secret is embedded into the client which makes MITM possible at this very point. As per this post, security.stackexchange.com/questions/63971/how-is-the-premaster-secret-used-in-tls-generated it has no relation with the public key of the server. Also, is the Server HELLO, certificate sharing done in separate calls (as depicted by you) ? if yes, isn't this bandwidth wastage? could you please clear out these doubts?
Hi kannan, great question! The secret key for the bulk encryption (i.e. AES) can change with every new session between the client and server. But, it doesn't always have to do this. It depends on how the server is configured to handle the encryption. For newer versions of TLS (1.3), the secret key will be required to change with every session between client and server. But for older TLS versions (1.2 and older), the key doesn't have to change with every new session. Thanks!
F5 DevCentral That's not what he asked, and it isn't correct. The Master Secret doesn't change until the session is invalidated, and can be used to generate numerous session keys within that session.
@@EJP286CRSKW, the point of the initial response was to say that the type of key exchange can affect the frequency of key changing. In RSA, the Pre-Master secret is computed in the browser. This Pre-Master secret is encrypted with the server's public key and shared with the server so that the client and server can later create the Master secret. In Diffie-Hellman, the client and server generate a new key pair for each session. The private keys of both client and server are deleted immediately once the Pre-Master secret is computed. Still, the Pre-Master secret is used later to create the Master secret. The point here is that, using Diffie-Hellman (or DHE), the keys can (and will) change with each new session. That said, it is also true that, when the Master secret is generated, there are a variety of "session" keys that are created. The RFC lists these as "client write MAC key, server write MAC key, client write encryption key, server write encryption key, client write initialization vector (IV), and server write IV. Not all of these will be used (the IV keys are not always needed) but it is true that more than one set of "session" keys will come out of a given Master secret. Thanks for contributing to the conversation on this.
each client generates a unique symmetric key, how does the server stores all these symmetric keys ? if million unique users hit a website does that mean that the server stores million symmetric keys?
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
What I dont understand is how this makes the data secure by any means, cant a cleverly designed software follow all this communication and end up with the same symmetric key at the end (assuming the attacker is able to sniff every single package sent back & forth)?
After receiving the server's certificate, the client generates a Pre-Master-Secret. They then encrypt this with the server's public key (extracted from the server's certificate). The client then sends the encrypted Pre-Master-Secret to the server. This is the crucial bit: only the server will be able to decrypt the encrypted Pre-Master-Secret. This is because only they (the server) possess the private key required to decrypt anything that is encrypted with their own public key. So even if an attacker could sniff all the packets sent between client/server, they wouldn't be able to decrypt the encrypted Pre-Master-Secret (since they don't possess the server's private key).
Thank you, but in my feeling is that it's not enough organized as presentation. Cuts, got back several times, to add this and that. BIG/IP or Server: chose one of them and keep it. Of course I'm speaking for myself, but I would prefer you to follow much more your paper you are looking at in your presentation. Anyway, thank you
Hi john : great video, one question : If I am using the ssl client and server profile in which part Of the handshake that the certificates are validated for identity ? For both client and server side ?
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
Excellent break-down of the TLS handshake. John's explanations are clear and easy to understand. Thank you!
CLIENT:
- Browser wants to establish connection to a server.
- Client sends Hello’ message
- TLS protocol number (1.2,1.3)
- Cipher suite client supports
SERVER:
- Server sends ‘Hello’ message
- Server sends certificate file
- Includes server’s public key
- Server sends ‘Hello done’ message
CLIENT:
- Client checks that certificate file
- Checks if it has been revoked
- Checks if it is still valid
- Client generates ‘Pre-Master Secret Key’ (PMSK)
- Client pulls some characters from server’s public key, encrypts that with server’s public key, and creates Pre-Master Secret Key
- Based on PMSK, it will generate SYMMETRIC KEY from that PMSK that will be used for bulk encryption.
- Client sends ‘Client finished’ message
SERVER:
- Server decrypts PMSK with his private key
- Server creates SYMMETRIC KEY by decrypting PMSK. This symmetric key will be same as client’s symmetric key because it was encrypted with PMSK.
- Server sends ‘Change Cipher Spec’ message. This tells client to change from asymmetric to symmetric key exchange
- Server sends ‘Finished’ message
END:
Both of them have symmetric key used.
Great summary . Thanks
Is the server public key linked to the certificate? Or independent of it?
@@barnabyvonrudal1The certificate will have the Public Key
The waterfall analogy was outstanding, provided an excellent framework for further study.
Appreciate the note!
Wow this is great. It takes months to truly get your head around this but vids like this make it so easy to refresh my memory
Glad you enjoyed it!
The most thorough explanation of TLS Handshake. Thank you!
Glad you enjoyed it!
Thanks Xians for making this concept so easy.
after went through so many other videos. Finally got clear picture only from your explanation. Very good explanation, thanks !
Great to hear!
Video is mirror image flipped, and the tshirt he's wearing has the text printed also mirror image flipped. That's how he's able on the glass so well.
Now start learning some TLS!
first wait until I change from 240p to 1080p maybe he wroth it flipped ,
Thanks. Thought that was going on but I was so distracted considering what if he was just so good writing backwards, that I had to rewatch halfway to pay attention.
See thats the first thing i was thinking and then scrolled through the comments to find out and you are top comment so thanks bro
My mind is flipped. My eyes take in light flipped too. Double flip.
Perfect explanation. I thought every time we encrypt with server certificate public key the whole time but it's not.
Thanks for the comment and glad you enjoyed the video!!
That was an amazing explanation, perfectly understood having the basics. Thank you
glad you enjoyed it!
This is CooL. Better explanation than Google's IT certification video! Thanks a lot!!!
glad you enjoyed it!
Best explain I'd ever seen.
We appreciate the comment! Glad you liked it!!
Wow, it is amazing to know what happens behind the scenes. I would like to meet the people who create/invent these things.
Great video, simple explanations, not dumbed down, not too technical. Good learning experience.
glad you liked it!
hi liva236muzika~ was wondering if we could use your quote for a little promo?
Yeah, no problem. Let me know when you put it on RUclips or wherever, I would love to see it.
Actually added it to a tweet: twitter.com/devcentral/status/973325328314707970 RT if you have a handle! Thanks again!
another good explanation need to watch a few times
Glad you liked it and we appreciate the comment!
Nice explanation! Thank you.
Glad you liked it and we really appreciate the comment!
what technology is he using to present? Is this a camera trick or a special screen?
Behind the Scenes: ruclips.net/video/U7E_L4wCPTc/видео.html
Great explanation. Breaking something down that takes microseconds to complete into a 12min video.
So, the communication starts with asymmetric cryptography and finishes with symmetric cryptography, so we have a hybrid cryptography. Very very good!
The asymmetric part is used for key distribution. The symmetric is used to reduce overhead and retain good performance.
Chris Torok The PKI part is used for authentication. Asymmetric encryption isn't used at all except in the now deprecated DH cipher suites.
That was entertaining to watch :)
Thanks.
Appreciate the comment!!
Thank you for helping me better understand this. I'm studying for my cert and I kinda understood reading it but this makes more sense! Awesome video and explanation.
Thanks Terrance...glad you enjoyed the video!
Very well explained, pretty useful.
Glad it helped and thanks for the comment!
amazing and easy to understand
We appreciate the comment and glad you enjoyed it!
Excellent discussion. Thanks!!
glad you enjoyed it!
Superb!
glad you enjoyed it!
Very Informative, thanks
Glad you enjoyed it!
Great Video. One question, how often does that process kick off?
Awsum teaching skills you have great for a fresher like me.................love from India
glad you enjoyed it!
Very good explanation!
Thanks!
Just what i was looking for. Appreciated
Glad you enjoyed it!
Thank you for explaining things perfectly!
And thank you for the comment!!
Its really amazing explanation on TLS handshake Thank you ... Just for my curiosity which application you used to record video with screen whiteboard option.
Thanks for the comment! This is how we create these: ruclips.net/video/U7E_L4wCPTc/видео.html
Well explained. thanks a lot 👍
Glad you liked it and we appreciate the comment!
super fkng awesome explaination
Thank you so much and thanks for the comment!
Awesome video
glad you enjoyed it!
this guy know things...
glad you enjoyed the video!
Very good. Well done.
glad you enjoyed it!
Thanks and that was great video. Have one question in the actual data transfer , the data is encrypted with symmetric encryption and the symmetric key is encrypted with asymmetric encryption for each session?
Thanks for the comment satksd! The whole point of the asymmetric encryption is to share the encryption keys for the symmetric encryption. So, for a given session, the client and server will begin by using asymmetric encryption to share the keys that they will both use for the symmetric encryption. The symmetric encryption is used for encrypting all the data that is sent between the client and server during that session. So, once the symmetric encryption keys are exchanged (via the asymmetric encryption), then the asymmetric encryption is not needed any more until a new session is established and new keys need to be exchanged.
Brilliant way to explain the concept....loved it
glad you enjoyed it!
I don't understand when Difie Hellaman is used here. And why is it actually needed? Why a signed certificate with public key is not enough?
Thanks for the great question! In this particular example, the key exchange is RSA. So, you wouldn't see Diffie Hellman in this specific example. Here's a video of how Diffie Hellman would be used: ruclips.net/video/pa4osob1XOk/видео.html
@@devcentral Thanks man :)
Thanks! Pretty good explanation of how the TSL handshake works. Got a question around how the symmetric key is generated. So based on the video looks like, we create that pre-master secret from contents from the certificate that the server shared plus a key that client generates using some tools/security suite on the fly. Client then encrypts it using the public key that server shared in the certificate. Then client send it to the server. Server then decrypts it with the private key. The resultant decrypted content would then content the shared encryption key. Is my understanding right? Is there a security suite that needs to be present in the client to create such shared key? So shared encryption key generation is the responsibility of the client, correct?
Hi Sailesh...great question! When the client initially contacts the server to initiate the secure connection (CLIENT HELLO for TLS), the client sends a list of cipher suites that are available for use on the client browser. In that cipher suite is a list of possible symmetric encryption algorithms that could be used (most of the time, the symmetric encryption type is AES). When the server gets the list of cipher suites from the client, the server checks to see if any of the cipher suites match what the server is willing to use (the server has a pre-loaded list of cipher suites that are configured for that specific server). The server picks the cipher suite that best matches its list of cipher suites (at least one has to match or else the connection gets terminated). Then, when the cipher suite is established, it tells the client and server exactly what kind of encryption methods will be used for that session. For example, Diffie Hellman could be used for key exchange while AES is used for symmetric encryption. So really, both the client and the server are involved in the creation of the symmetric encryption key, but the server is the one that gets to drive the choices (with picking the cipher suite and also sending its public key for initial encryption). I hope this helps!
And, for more on cipher suites, you can watch this lightboard lesson. Thanks!
ruclips.net/video/ZM3tXhPV8v0/видео.html
@@devcentral I feel that things are lot clearer now about the symmetric key mechanism now that I have gone through few of the videos and the comment from you guys here. Agree that both server and clients are involved. But, someone still has to create the shared key that both the party agree to use. Are they generated on the fly? Am I missing something?
@@devcentral Thanks for sharing. I had already seen that video which gave much better understanding about shared encryption. But, even going through them things were not clear how shared encryption key gets generated.
amazing vid thanks so much
Glad you liked it and thanks for the comment!!
Amazing!
glad you enjoyed it!
Very good. Thank you. I would like to learn how the symmetric key is first generated by the client.
Great question! The math behind these calculations can get pretty tricky, but here's a link to some good info on the key generation topic: stackoverflow.com/questions/3936071/how-does-browser-generate-symmetric-key-during-ssl-handshake
Great Video..!! One quick question.. How does the client verify that the (certificate and the public key) is coming from Big-IP not from an anonymous attacker?
I believe this is what Cert authorities are for / root cert on the client.
But would love a detailed answer
Great question! The certificate is signed by the Certificate Authority (CA) so the client can use that signature as the validation that the certificate is from the proper sender. The server typically sends a Certificate Signing Request (CSR) to the CA to get a signed certificate for the server. Then, the server can send that signed certificate to the client so that the client knows it has been signed by the CA.
I'm left with one burning question.
How did you learn to write backwards so well?
I wanted to ask the same question
I'm pretty sure they've just flipped the video horizontally
They just flip while recording. He is not lefty by the way. Recording does the job here.
@@egregis21 I can read NEON on his pen at 7:09, looks like he is skillfully writing backwards.
@Narendra Solanki But title on his shirt???
Would be great to know the reason why the client does not send the calculated primary key right away to the server instead of the pre-master secret/key? Only the server can decrypt that message anyway ...
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
Great Content! can you please discuss tls upgrade for smtp server?
Thank youuu
Very well explained, thank you.
cool presentation. Questions: is the pre-master key actually exchanged, if so, what if man in the middle learned it, can it be used to create the eventual asymmetric key? Meaning during the TLS handshake is there vulnerability? 2nd question, is the final symmetric key ever exchanged? thanks.
The pre master secret is shared but encrypted with the public key of the server (found in the server certificate). That way even if someone can tap into the message they cannot decrypt it unless they know the servers private key.
In what sequence will TCP handshake and TLS handshake happen? Which one happens first in a connection?
Hi Azza...great question! The TCP handshake will happen first and then the TLS handshake. Thanks!
Awesome explanation.
But I didn't get the difference between Pre-master secret and symmetric key. As per my understanding they are different names to the same key. Could someone please correct me?
Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
@@devcentral Thanks a lot 😀
Thanks! You guys as always Rock!!!
glad you enjoyed it!
very, very, very nice. Thank you very much. Small question: what means by (bulk data)?
glad you enjoyed it! bulk encryption (and thereby, bulk data) is the data transmitted between client and server after the key exchange takes place. This is, by far, the most data transmitted between client and server. The key exchange is simply there to exchange the keys that will be used in the symmetric (bulk) encryption.
Well explained👍
glad you enjoyed it!
very nice explanation, thank you very much.
glad you enjoyed it!
Great vid! Now that you have a video about certificates it'd be helpful to have a link to that in this video's description. Thanks
Great feedback! I just updated it. Thanks!
im a little confused... wouldn't it suffice if only one side generated a symmetric key? why is it necessary that even though it's the same symmetric key in a way another one would be generated by the web server?
Great question! In order for the cryptography to work, one side must encrypt the data and then the other side must be able to decrypt the data so they can read it. The way symmetric cryptography works is that the same key (same value) does both the encrypting and decrypting. So, if only one side had the key, then they would be able to encrypt the data, but the other side wouldn't be able to decrypt it. So, both sides need to compute the exact same symmetric key so that they can each use that key to encrypt/decrypt. I hope this helps!
@@devcentral That makes sense!. This computing of the same symmetric key applies to all symmetric encryption right and not only in this case scenario?
@@sulekha3771 yes, all symmetric encryption requires that the sender and receiver both have the same key.
@@devcentral I know but rather than both the sender and receiver having 1 key as I thought before they will both compute the same key (individually) to use to encrypt & decrypt data
@@sulekha3771 yes...that's right!
Thank you 😊 is this tls 1.2 or 1.3?
This is TLS 1.2 and prior. I did a TLS 1.3 handshake video here: ruclips.net/video/yPdJVvSyMqk/видео.html
you here Hussein ?
Does symmetric key encryption used on top of the asymmetrical encryption, or do both nodes switch over to symmetric encryption? If so, why not asymmetrical to host and symmetric back to client?
Hi Christopher...great questions! The asymmetric encryption is used at the beginning of the handshake and the primary purpose of this is to share/create the keys that will be used in the symmetric encryption. Both sides start with asymmetric and then (once the symmetric keys have been created and verified), they both move to symmetric encryption for the duration of the session. I hope this helps!
@@devcentral I figured that had to happen somewhere. Thank you
whats the role of "client random number" and :"server random number" in generating the final symmetric key ?
Great question, Mike! The random numbers are used to calculate the symmetric key used for the bulk encryption algorithm. I did a video on how the RSA algorithm works here: ruclips.net/video/rVQpK6NcYIE/видео.html and I also did one on how the Diffie-Hellman algorithm works here: ruclips.net/video/pa4osob1XOk/видео.html
I hope this helps!
very good video thanks for sharing, one question, what is the encryption algorithm used to exchange communication between client and server ? is it AES ? thanks
Hi Diego...great question! The encryption algorithm used to exchange communication between client and server is negotiated in the initial part of the TLS handshake. That said, AES is almost always used in modern web applications today. I hope this helps!
@@devcentral Thanks for the reply ! another question... if you proceed to a site which is not using a valid certificate and then you get the warning and click on "proceed to unsafe" does the ssl handshake still happen ? if so, does encryption happen even if the certificate could not be validated ? Thanks
@@diegoramos27 great question! yes, even if the certificate is not valid, the TLS handshake should still complete (although it's possible to configure to drop the connection if the certificate is invalid). In this case, the client and server would still have an encrypted connection, but the client just wouldn't know for sure that the web server is the correct one.
How is the symmetric key generated, exactly? And how can the server generate it in a way that matches what the client generates?
they use diffie hellman key exchange
No, Akash... Diffie Hellam does NOT have to be used.
Remember,
the client sends over the *Pre-shared master key.*
Okay... so what's that exactly?
Well... its basically the *recipe* for the "symmetric key."
However, the client does NOT send the "recipe" in *clear text.*
Instead, the client ENCRYPTS the recipe using the Server's Public Key (aka, the certificate)...
and THEN its sends it to the server.
:]
nice videos. like your explanation on these topics. keep em coming.
maybe next video about in depth certificate's?
thanks!
Also, here's another one I did on "what's in a digital certificate?"
ruclips.net/video/XmIlynkR8J8/видео.html
Enjoy!
So the client does not have to provide it's own certificate? Or is that optional?
Hi Chilly Vanilly...great question! The client is not required to provide its certificate unless the server is configured to require client authentication. Then, the client would need to present a valid certificate to prove who they are in order for the handshake to complete. Thanks!
@@devcentral Ah, okay, thank you kindly for the quick reply! Great vid btw!
@@chillyvanilly6352 Cliennt's usually provide a username/password to CONFIRM who they are.
Thats the reason you are able to "LOG IN" in order to read your email.
:]
What's stopping a hacker from using the symmetric key on the client side to communicate with server after it's generated? Does that question even make sense?
Great question!! If an attacker were to get the symmetric key from the client, he could definitely decrypt all communication between client and server. This is why it is so important to secure the symmetric key. This is also one of the reasons many clients and servers are moving to "Perfect Forward Secret" ciphers so that the symmetric key changes with every new session. Here's more info on Perfect Forward Secrecy in case you are interested: ruclips.net/video/IkM3R-KDu44/видео.html
Hope this helps!
In registry of one machine, If we enable client tls 1.0 and server tls 1.2 enabled, rest all disabled. Will it still allow communication?
Great question Mahendra! It all depends on how you configure, in this case, the server. If the client is using TLS 1.0 and the server is set to use TLS 1.2, then you can configure the server to abort the TLS handshake when it realizes the client can't use TLS 1.2. Or, you can configure the server to allow a downgrade to TLS 1.0 when it realizes that the client can only use TLS 1.0. So, it depends on how you configure the client cipher suite. I hope this helps!
@@devcentral Thanks John for your reply. Glad to hear from you. Much appreciated, if you can explain along with sample client/server communication example.
beginner question here... why not just the client generate the symmetric key, encrypt it with the public key, send it to the server. The server decrypts the message with its private key to obtain the shared symmetric key?
Jason, the client needs to verify that the server is who they say they are before sending it’s own key, hence it first negotiates with the server to get the servers public certificate. Once the client has the certificate and public key it checks with a certificate authority (third party check which is briefly mentioned, but not drawn in the video) to verify the server is who the client expects it to be, only then will the client start negotiating symmetric keys.
@Jeggle Publishing Thank you for taking the time. I understand the initial authentication handshake but I appreciate you not making that assumption. My question pertains to what happens after, the necessity of the simultaneous calculation on both sides with the premaster as input to arrive at the symmetric encryption key. Could the client just have come up with this symmetric key, encrypt with the server's public key, send it. both sides acknowledge to use the symmetric key from then on?
@@jasonb3200 LOL
Honestly... what you proposed... is basically what happens anyway.
LOL
You're saying that, after the client CONFIRMS that the server is REALLY who it claims to be....
"WHy doesn't the client just SEND the symmetric key directly?"
But.. it doesn't.
instead, it sends the *Pre-shared master key.*
Okay... so.... what exactly is that about?
Well... its basically the *recipe* "for" the symmetric key.
It's the equivalent to "ME" needing to send "YOU" my grandma *special* German Chocolate cake.
i have the ingredients... i have the Oven... and i have the recipe....
so i could put in the *TIME & EFFORT* to "bake the cake" and then send it to you.
Or,
at the end of the day... i know that:
You already have the Ingredients,
You already have an Oven....
So... it's actually easier if i just *SEND you my grandma's RECIPE...* and then you can BAKE the cake yourself.
At the end of the day.... think about it this way:
which is EASIER to send to someone:
a) a German Chocolate Cake,
or
b) the *recipe* for a German Chocolate cake.
?
The key exchange probably follows the *same* reasoning.
:]
Great video and explanation! Thank you very much!
GREAT video, thanks!!
glad you enjoyed it!
So, we can get 1 symmetric key (ONLY) out of Pre Master Secret ? The reason I ask, if both server and client are able to generate 1 symmetric key out of 1 PMS, I would think the answer is 1.
Hi...great question! The purpose of the Pre Master Secret is to ultimately create a shared symmetric key that the client and server can both use for the duration of that particular session. When the session is over (or renegotiated, etc), then the client and server will generate a new symmetric key for the new session. There would only need to be one pre master secret used to generate the shared symmetric key for a given session. But, like I mentioned, this entire process would happen again for any new sessions between the client and server (or a different client and the server). I hope this helps!
@@devcentral Thank you for the explanation.
F5 DevCentral Wrong. The master secret can be used to generate any number of session keys within the session.
Excellent explanation. Thank you.
Glad you enjoyed it!!
Thanks a lot , same I was looking for
glad you enjoyed it!
Does it protect TCP header and payload both? Or just the payload?
nice 🔥🔥
Appreciate the comment!
thank you for this nice explanation!
glad you enjoyed it!
Thanks & really appreciate your work .
I have one question here :
at 7:51, should Change Cipher Spec be sent before Client Key Exchange or after that ?
I think Change Cipher Spec should be the last one sent in plaintext (accroding to RFC5246) , but not sure if we must encrypt Client Key Exchange before sending it out.
Thanks for the video!
THANKS MAN
As far as i know there's nonce in the handshake process. I know it's used to prevent some replay attack but I wonder if nonce is used to create pre master secret.
Or Is pms only genereated from server's public key?
why does the client send the Pre Master secret and not immediately the symmetric key?
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
I got everything but I have a single doubt. Pre master secret is derived from public key. And then it is encrypted and shared with the server. And then server has the same pre master key. And now both client and server makes a symmetric key. How? What kinds of algo do they use? And how do they ensure that they make the same symmetric key?
And where is this symmetric key stored in the server?
And how are these public keys and private keys decided by the server before sending to client? During the deployed of the application? Do the developer provide public and private keys?
Is this allowed? Doesn't it have to be an elbow bump?
lol
i see what you did there...
@@HughJass-313
Awesome info
How does it complete the transaction and tell the other side not to use that private key anymore?
Great question! The "change cipher spec" message essentially alerts the other side that it's time to move to symmetric encryption. Plus, all future messages after that are encrypted using the symmetric key instead of the public/private key pair. Thanks!
Thanks for the quick reply! How is the data transfer process terminated and the symmetric key discarded?
@@siddharthmanumusic once the client and server establish the shared symmetric key, they use that key for encryption/decryption for the duration of that specific user session. Sessions typically last for as long as the client has the browser open to that specific page (or pages) or until there is no more client activity (like, when you visit a banking page and then don't take any action, they will sometimes ask if you are still there or want to extend the session). Thanks!
F5 DevCentral Thank you! So when the TCP session ends, at the protocol level...
Siddharth Manu The session key can be changed within the session, via an abbreviated handshake.
Man this is TECH NF
Great stuff,thanks for sharing!!!
glad you enjoyed it!
Thanks for the video. One question I have.
You mentioned that when server sends its certificate to the client, it also sends its public key. In this case, any MITM attacker can replace this certificate with its self-generated certificate signed using his private key and send to the client with his public key.
So, client will have no way to identify if the cert+public key it received is from the actual server or from the attacker. Is my understanding correct?
Hi Harshit...great question! You are exactly right that a MITM could step in and send a self-generated certificate signed by his own private key. The issue, though, is that the MITM will have to get someone/something to sign the certificate. The easy answer is for the attacker to sign the certificate himself, but all modern browsers will notice that a certificate has been "self-signed" and will prompt a warning page to the user saying that the page you are attempting to view has a certificate that has been self-signed. The idea is that the Certificate Authority has to sign the certificate in order to avoid the browser warning page. And, a Certificate Authority is not going to issue/sign a certificate for a secure website that already has a valid certificate. The Certificate Authority is supposed to check these things before they ever issue a certificate and public/private key for a given website.
Here's a quick article that I found that goes into a bit more detail: www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/
I hope this helps!
@@devcentral Thanks for the detailed explanation. Now I got the answer.
@@devcentral But this in turn requires the Certificate Authorities to exists, so we're back to square one, because this requires trusting the Authorities :P And they can be the biggest Men In The Middle here, because of the scale of their power and lack of suspicion from the clients :q Imagine someone hacks the CA and swaps the keys to their own (happened already). Why do we need CAs anyway? Can't we do a two-sided key exchange without them? :q I see this entire CA thing as another huge pyramid scheme to squeeze money from people for selling certificates to them :q
Bon Bon The answer is not correct. What he's omitted is that the CertificateVerify message which is sent after the Certificate message contains a digital signature signed by the private key, and that can be verified by its public key. So only the owner of that public key can create a valid CertificateVerify message.
EJP is correct .. Every browsers have CA root bundles installed which has the public key of trusted CA's who able to verfiry the sigature in certifcate which signed using their(CA) own private key at the time of CSR.. So any MITM hacked and replaced the certificate ,signature cannot be verified by browser and I think you will see warning message or connection may be dropped..
As far as I can understand, the first 4 steps(until hello done from big ip) are not encrypted . Or the first hello from client also includes its public key. I am confused. Please explain.
client never send its public key to server, client only use server's public key to encrypt message, while server can decrypt the message coming from client with its private key.
after decryption, server knows the suggested pre-master-secret from client, then use its private key to encrypt pre-master-secret to create a symmetric key, send it back to client, client can decrypt this symmetric key by servers public key, if client get the original pre-master-secret, then it proves client is talking to the intented server, because by now no 3rd party knows this newly created symmetric key, for later communications client can use this symmetric key to encrypt, and server can use the same symmetric key for decryption.
But what is the pre master secret? ;/
Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
I have a doubt,
Since you said Pre-master secret is generated from the public key that means the logic to derive the secret is embedded into the client which makes MITM possible at this very point.
As per this post, security.stackexchange.com/questions/63971/how-is-the-premaster-secret-used-in-tls-generated
it has no relation with the public key of the server.
Also, is the Server HELLO, certificate sharing done in separate calls (as depicted by you) ? if yes, isn't this bandwidth wastage?
could you please clear out these doubts?
Does the Master- Secret key keeps changing?
Hi kannan, great question! The secret key for the bulk encryption (i.e. AES) can change with every new session between the client and server. But, it doesn't always have to do this. It depends on how the server is configured to handle the encryption. For newer versions of TLS (1.3), the secret key will be required to change with every session between client and server. But for older TLS versions (1.2 and older), the key doesn't have to change with every new session. Thanks!
F5 DevCentral That's not what he asked, and it isn't correct. The Master Secret doesn't change until the session is invalidated, and can be used to generate numerous session keys within that session.
@@EJP286CRSKW, the point of the initial response was to say that the type of key exchange can affect the frequency of key changing. In RSA, the Pre-Master secret is computed in the browser. This Pre-Master secret is encrypted with the server's public key and shared with the server so that the client and server can later create the Master secret. In Diffie-Hellman, the client and server generate a new key pair for each session. The private keys of both client and server are deleted immediately once the Pre-Master secret is computed. Still, the Pre-Master secret is used later to create the Master secret. The point here is that, using Diffie-Hellman (or DHE), the keys can (and will) change with each new session. That said, it is also true that, when the Master secret is generated, there are a variety of "session" keys that are created. The RFC lists these as "client write MAC key, server write MAC key, client write encryption key, server write encryption key, client write initialization vector (IV), and server write IV. Not all of these will be used (the IV keys are not always needed) but it is true that more than one set of "session" keys will come out of a given Master secret. Thanks for contributing to the conversation on this.
each client generates a unique symmetric key, how does the server stores all these symmetric keys ? if million unique users hit a website does that mean that the server stores million symmetric keys?
Why doesn't the client just send a symmetric key to the big IP? What is the reason of the additional step with a pre-master secret?
Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
I see now. Thank you for your videos. You're doing a great job!
Bro, Symmetric is based on PMK which is generated via public key of server ,so we need to have these steps
F5 DevCentral Not really. The basic idea is never to transmit the session key, so it can never be intercepted.
What I dont understand is how this makes the data secure by any means, cant a cleverly designed software follow all this communication and end up with the same symmetric key at the end (assuming the attacker is able to sniff every single package sent back & forth)?
After receiving the server's certificate, the client generates a Pre-Master-Secret. They then encrypt this with the server's public key (extracted from the server's certificate). The client then sends the encrypted Pre-Master-Secret to the server. This is the crucial bit: only the server will be able to decrypt the encrypted Pre-Master-Secret. This is because only they (the server) possess the private key required to decrypt anything that is encrypted with their own public key.
So even if an attacker could sniff all the packets sent between client/server, they wouldn't be able to decrypt the encrypted Pre-Master-Secret (since they don't possess the server's private key).
Thank you, but in my feeling is that it's not enough organized as presentation. Cuts, got back several times, to add this and that. BIG/IP or Server: chose one of them and keep it. Of course I'm speaking for myself, but I would prefer you to follow much more your paper you are looking at in your presentation. Anyway, thank you
what does TLS stand for?
Transport Layer Security. It's the successor to Secure Sockets Layer (SSL). Here's more info on it: en.wikipedia.org/wiki/Transport_Layer_Security
T.otally
L.ame
S.ecurity
;)
Could you do an video what describe ChaCha20 and Poly1305 that Chrome/Google uses ?
Hi john : great video, one question :
If I am using the ssl client and server profile in which part
Of the handshake that the certificates are validated for identity ? For both client and server side ?
I believe this is done through the CA - or Certificate authority, at least validating the Servers identity.
In this video the server does not request of the client to authenticate itself. Client authentication is optional but some connections require it