I should salute for all your efforts of these videos. It's really helpful for me. You're massive of crispy to the point. I don't know where I can give you kudos for your work.. Thanks a lot.
@@dilipbalaiyan6268 Glad you are getting a lot out of this content. If you're really wanting to help, the best way is to spread the word about this content =). Shares on Twitter/LinkedIn/Reddit are greatly appreciated. Cheers, Dilip.
I wanted to take a moment to thank you for your incredibly helpful tutorial on TLS/SSL. I'm so grateful that you took the time to create such a detailed and informative resource.
Thanks for all your quick responses here and on Twitter! Until I buy a class just wanted to say thanks as you are great at fulfilling your mission of bridging the gap between overly technical documentation, RFCs etc and simplified examples that leave us with more questions than answer!!! Keep it going and thanks again!!
One of the absolute best training videos I've watched in the recent past! The author seems to have an impressive understanding of the audience new to the topic. Pacing of the video is spot-on for me, making the learning experience truly captivating
I kept struggling with those 5-6 min long videos on TLS/SSL handshake and was sure I needed to find a longer all-in-one video, and yours is really by far the best explanation here, thank you, I hope RUclips's algorithm will recommend this to more people who search on this topic
As someone lucky enough to have won access to the full TLS course, I have to agree that there is enough detailed content in it to answer any questions a person may have after watching this. Excellent course! Definitely worth the cost! 👍 Really, really looking forward to 1.3 with quic.
Excellent!!! I needed/wanted to know TLS at that level. I do, however, have to research the certificate chain part - from practical experience and industry-renowned services like Qualys SSLLabs it is expected to configure a web server with its certificate and the CA chain EXCEPT the root certificate! Because the root CA is a trust thing the client (browser) has to assess on its own anyway but the diversification in intermediate CA hierarchies and (internal) technical requirements of a specific CAs is something the client cannot know in its entirety. So we "make a ladder" for the client up to the root.
THANK YOU!!! so many different videos separate everything and its hard to really understand the whole topic and how it fits together. Thank you for doing what nobody else does
Simply and ABSOLUTELY fantastic content! I’m sold and now a paid course subscribed student looking forward to consuming ALL the content and putting it to practical use! Kudos! MM
OMG! Thank you so much!!! This was EXACTLY the video I needed to understand what was missing, and I was looking for it so badly! Best explanation ever!
You have a small mistake: Session ID is variable length and can be up to 32 *bytes*, not 32 bits. See page 40 of RFC 5246. Otherwise amazing video. Thank you so much, really helpful to prep for my interview tmw :)
Hi! I study cryptography and your videos are the best in the whole Internet! Could you please specify the exact way of combining pre-master key\master-key with random values and strings before putting them into PRF? With love from Ukraine
I want to Thank you for all the content you made to create such a wonderful playlist. It took me a while to understand whats going but it all makes sense. It’s so fascinating and it blows my mind that smart people created a secure tunnel for secure communications. Me in my 30s as a employee in a facility management company trying to make a step into information technology and let my path of life go in a new direction. Unfortunately I can not afford a full TLS course from your website but let me spend you a coffee at least. Thank you so much man. God bless you Is there name of your song you always use for intros? I would like to listen to it, while thinking about the TLS handshake step by step 😊
Thanks for the kind words, and thank you for supporting the channel. I'm at the gym at the moment, and don't recall what song I used in this video. But if you reach out to me on discord, I'll tell you the song... And gift you a scholarship to the course.
Hi Ed, at 8:40, i have the below questions: 1. Does the server always provide the root CA in the certificate chain? 2. if the intermediate CA is not provided by the server, how does the client decrypt the digital signature? 3. if the server provides the root CA, does the client use the public key of the root CA provided from the server, or the public key from the Client's own CA cert store? (i assume it's the latter)
Must say that if we were to speak of only the Handshake then this is the best video, would request you to cover the Certificate Change of Trust, Record and Alert Protocol as well. Thank you
absolutely incredible video. this is the one greatest explenation of TLS I've managed to find. thank you! I hope my cyber security course test score will show I've understood the protocol :)
just would like to clarify that the process described in this video is for key exchange algorithm using RSA right? If DHE is used, the server key exchange (with the DH public paramaters) message should be sent after the certificate record and before the server hello done record.
Thanks for this video. I have a question related to session keys generation. How Master Secret, Client and server random and "key expansion" are used or combined in order to generate these 4 session keys? My second question is how Master secret is actually generated? You said we combine Pre-Master secret, client and server random and "Master Secret" but what mechanism or algorithm is used to generate it?
This vide is awesome 💯 just having a little doubt from where did that key expansion field come which is been used for the formation of the session keys
so RSA only here for key exchange? no encryption other than symmetric keys? is it then that the symmetric cipher comes into play with the keys to encrypt the payloads? is the hashing of handshake determined by cipher suite selecion for example SHA1?
Correct. RSA just facilitates the key exchange, and signatures. It doesn't do any real encryption of data sent being client and server. Yes, hashing is determined by Cipher Suite selection.
I was so shocked about all the things that are being done behind the scenes when you access an https website that I'm thinking that I would be exhausted and do not want to exchange data anymore after that long handshake haha
4 месяца назад
I just wanted to say thank you for your amazing tutorial on TLS/SSL. I really appreciate the time and effort you put into making such a comprehensive and informative guide.
Any videos doing a similar walk through but with Diffiehellman key exchange? Specifically on and where in the flow the client verifies that the server does possess the long term private key that corresponds with the earlier served x509 cert? Because it doesn't need to send a premaster secret like RSA where is this same validation check performed with Diffiehellman? Ex 11:10
Great question! I don't have a video answer but the pinned post on my Twitter is exactly what you asked for: a walk through of the TLS handshake using diffie hellman as a key exchange. =)
Ed... please refer the video @11.26...what if the middleman sends server his own pre-master-key encrypted using server's public key. I guess server's public key is available to everyone. In this case, how does the server ensure's that the pre-master-key (encrypted with server's public key) it receives is from the actual client and not from someone else. BTW thanks for the video Ed.
Great course Ed! I have a question on the Cipher Suites used (trying to go through the comments if it was asked before, but can't seem to find it, therefore I apologize for asking "again"). In TLS1.3, all RSA encryption and RSA cipher suites have been removed. The video started by Client having TLS1.3, but did not mention TLS1.2 libraries as well. Is it assumed in this course that Client and Server have both 1.2 and 1.3 for this handshake to work for this course?
Great video. For @17.00 - Can you please help clarify if the client encryption key gets generated individually at the client and the server? If so, client and server have the same set of 4 pieces of information (Master Secret, key expansion, Client Random, Server Random) that is used for the random hash function. But how is it guaranteed that the random hash function returns the same value both at the client and the server?
The nature of Hashing is that if the Client and Server hash the same pieces of information, they will receive the same output. That is what is happening here, and how the encryption keys calculated by both Client and Server end up being identical.
@@PracticalNetworking To Clarify this further, does this mean that the Client keys are generated using the client random number and the server keys are using the server random number to be generated? otherwise how can you make two sets of keys individually on each host and ensure both sets are the same?
Yea, that's totally a typo. Someone mentioned this in my discord as well. It should say any range in 0-32 bytes. In reality, there is one field "Session ID Length" which is always 1 byte (8 bits, values 0-255, of which only 0-32 are valid) which indicates how long the actual "Session ID" field will be.
Yes, typically. There is a version of TLS over UDP that doesn't involve TCP 3 way handshake, but generally most TLS does. I have some videos on TCP here : pracnet.net/tcp
Could you help clarify what's been explain at 14:40? The concept of two tunnels. Up until that point you've been saying that the keys both the client and the server have are identical. But you go into how TLS creates two tunnels and they are encrypted with two different pair of keys, and that even if one of the tunnel's been comprised, the attacker can only decrypt that tunnel and not the other. How does that work? Aren't both set of keys the same?
I think I may have understood it. BOTH the CLIENT and SERVER generates a SEED for it's respective tunnels that BOTH perform a RSA Key exchange for. Correct me if I'm wrong.
Q: If a client initiates TLS 1.0 to a server and gets denied, will it open a new stream to renegotiate the higher TLS with the server or will it use the same quintuple stream on renegotiation?
Great content😊😇.. But, .I stucked in some points.. What is exactly "masterkey" inside the "pre-master key". And then "servers finished".? Is that same value both side?
"pre-master-key" is a random value generated by the client (at least, with the version of the handshake illustrated in the video). This random value is combined with other values to create the "Master Secret". Which is then combined with yet other values, such as the literal string "Server Finished", to create the actual Session Keys
Why do we need to generate master secret from pre-master secret + client random + server random? Why can't a client generate a master secret right away and encrypt it with server's pub key?
My question is client send lists of cipher suite to server. What mechanism is work on server side and server choice one of cipher suite that client send in hello message
Thanks a lot Ed! I have a query regarding slowness issue between two servers (these servers residing in DC and branch office and communicating via meraki vpn) this issue occuring after upgrading our gear to meraki not sure what's the issue here could you help me with some troubleshooting steps please Thanks in advance
That seems pretty involved, much more involved than what is appropriate for RUclips comments. You can try to ask in discord (pracnet.net/discord) but the issue is borderline something that would require hiring a consultant (which, I'm available for, if you are interested).
@@PracticalNetworking thank you for the reply Ed! It indeed need consultant view will have a word with my manager on this and get back to you thank you again
📢 *Black Friday / Cyber Monday Promotion*
👉 Practical TLS for only $50 (originally $297)
💻 Use code *BFCM2024* --> pracnet.net/tls
📅 Offer expires Dec 6
I should salute for all your efforts of these videos. It's really helpful for me. You're massive of crispy to the point.
I don't know where I can give you kudos for your work.. Thanks a lot.
@@dilipbalaiyan6268 Glad you are getting a lot out of this content. If you're really wanting to help, the best way is to spread the word about this content =). Shares on Twitter/LinkedIn/Reddit are greatly appreciated. Cheers, Dilip.
@@PracticalNetworking definitely
@@dilipbalaiyan6268 Thank you kindly =)
Its worth every penny, such a small price vs large reward! Great work Ed!
I wanted to take a moment to thank you for your incredibly helpful tutorial on TLS/SSL. I'm so grateful that you took the time to create such a detailed and informative resource.
You're very welcome.
If you want more, you might also enjoy the full TLS course as well.
Thanks for all your quick responses here and on Twitter! Until I buy a class just wanted to say thanks as you are great at fulfilling your mission of bridging the gap between overly technical documentation, RFCs etc and simplified examples that leave us with more questions than answer!!!
Keep it going and thanks again!!
Thanks for the kind words. Glad to help. Thanks for supporting the channel =)
One of the absolute best training videos I've watched in the recent past! The author seems to have an impressive understanding of the audience new to the topic. Pacing of the video is spot-on for me, making the learning experience truly captivating
One of the best and highly detailed explanations of TLS Handshake.
Thanks for putting this out for free !!
Thank you for the kind words. You're very welcome, Umair.
I kept struggling with those 5-6 min long videos on TLS/SSL handshake and was sure I needed to find a longer all-in-one video, and yours is really by far the best explanation here, thank you, I hope RUclips's algorithm will recommend this to more people who search on this topic
after all these years in IT , now I fully understand TLS . thank you so much
Hey someone, can you please come back & remove your 'single' DISLIKE from this video please.
This insightful video doesn't deserve dislike at all.
Seriously! ;p
As someone lucky enough to have won access to the full TLS course, I have to agree that there is enough detailed content in it to answer any questions a person may have after watching this. Excellent course! Definitely worth the cost! 👍 Really, really looking forward to 1.3 with quic.
Thanks for the kind words, Scott =).
Excellent!!! I needed/wanted to know TLS at that level. I do, however, have to research the certificate chain part - from practical experience and industry-renowned services like Qualys SSLLabs it is expected to configure a web server with its certificate and the CA chain EXCEPT the root certificate! Because the root CA is a trust thing the client (browser) has to assess on its own anyway but the diversification in intermediate CA hierarchies and (internal) technical requirements of a specific CAs is something the client cannot know in its entirety. So we "make a ladder" for the client up to the root.
The most precise explanation of TLS handshake, I have ever found!! Thanks for making my life easy.
THANK YOU!!! so many different videos separate everything and its hard to really understand the whole topic and how it fits together. Thank you for doing what nobody else does
This is a gem! Thanks for your free course!
Lucky to come across this explanation..best for SSL handshake
This was beautiful video on internet. Thanks Ed
Glad you enjoyed it, Satishbabu!
The best ever TLS Handshake Explained..
Really appreciate all the work you do! This was very helpful, clear and detailed at the right level of abstraction. Thank you. 🙏
you know the video is good when you spend 2 hours on watching 30 min good job. I wish there were free access to the rest of the content.
I finally purchased your Practical TLS class last night. Ready!!!
Awesome! Welcome to the course!
As always you clear my doubt aboutTLS 1.2. Thank U Sir. Lots of Love from india. ❤️🇮🇳
You're welcome, Rudra. =)
The best explanation of the concept on the internet I have seen! Thank you.
This is the best explanation so far I got around SSL handshake. Thanks a lot!
Simply and ABSOLUTELY fantastic content! I’m sold and now a paid course subscribed student looking forward to consuming ALL the content and putting it to practical use! Kudos! MM
Glad you enjoyed it, Michael =)
very detailed and easy to understand. This was awesome, thank you
That was a really rough ride. But I'm glad I went through with it. Thanks for the video!
Beautiful can’t wait for the TLS 1.3
Thank you, Hamza.
I'm glad I subscribed to the channel after finding the website.
Me too =)
you are hands down the best teacher! i cant thank you enough. truly grateful 🙏
You're very welcome! Hope to see you in the full course soon!
Thank you
OMG! Thank you so much!!! This was EXACTLY the video I needed to understand what was missing, and I was looking for it so badly! Best explanation ever!
The best solid tutorial i have ever watched. Congrats 😅
This is a great video. Thanks a lot. You made everything very clear.
OMG !!
What an explanation Ed.
This is the best content for TLS-Handshake and i'm so glad to find.
Lots of love from INDIA
💌
Cheers Ankit. Glad you enjoyed it =).
You have a small mistake: Session ID is variable length and can be up to 32 *bytes*, not 32 bits. See page 40 of RFC 5246. Otherwise amazing video. Thank you so much, really helpful to prep for my interview tmw :)
Hi! I study cryptography and your videos are the best in the whole Internet! Could you please specify the exact way of combining pre-master key\master-key with random values and strings before putting them into PRF? With love from Ukraine
I want to Thank you for all the content you made to create such a wonderful playlist. It took me a while to understand whats going but it all makes sense. It’s so fascinating and it blows my mind that smart people created a secure tunnel for secure communications.
Me in my 30s as a employee in a facility management company trying to make a step into information technology and let my path of life go in a new direction.
Unfortunately I can not afford a full TLS course from your website but let me spend you a coffee at least.
Thank you so much man. God bless you
Is there name of your song you always use for intros? I would like to listen to it, while thinking about the TLS handshake step by step 😊
Thanks for the kind words, and thank you for supporting the channel.
I'm at the gym at the moment, and don't recall what song I used in this video.
But if you reach out to me on discord, I'll tell you the song... And gift you a scholarship to the course.
Hi Ed, at 8:40, i have the below questions:
1. Does the server always provide the root CA in the certificate chain?
2. if the intermediate CA is not provided by the server, how does the client decrypt the digital signature?
3. if the server provides the root CA, does the client use the public key of the root CA provided from the server, or the public key from the Client's own CA cert store? (i assume it's the latter)
Wow that was such a good explanation! Thank you heaps, I wish my tutors had a similar skill to transfer knowledge - it is a skillset of its own!
Crisp and clear explanation ever!
You sir, are a legend! Great video, well explained.
This is by far the best explanation I’ve seen on the internet. Thank you so much for sharing!! I’m sure this video has helped a lot of us here :)
Great video as always Ed! Since you're using the RSA key exchange, does this version of the handshake support PFS?
Yet again an amazing demonstration of excellence!
Thank you! Cheers!
One of the best session which i watched. Thanks for the detailed and clean explanation.
I hit the LIKE button 6 times to give you tha round of applause. You actually deserve it more than me. Thank you!
Thanks for the kind words and your support =) And the six likes ! ;)
Must say that if we were to speak of only the Handshake then this is the best video, would request you to cover the Certificate Change of Trust, Record and Alert Protocol as well. Thank you
GLad you enjoyed this video, Aniruddh! The rest of those topics are covered in the full course!
absolutely incredible video. this is the one greatest explenation of TLS I've managed to find. thank you! I hope my cyber security course test score will show I've understood the protocol :)
Thank you for the kind words =) Glad you enjoyed it!
best explanation about TLS Handshake! loved it!
Man 100K subscribers. It was way less a year ago. You are Networking great :))
Progress has been slow and steady, but it finally got to 100k =). Excited to see where it goes next !
just would like to clarify that the process described in this video is for key exchange algorithm using RSA right? If DHE is used, the server key exchange (with the DH public paramaters) message should be sent after the certificate record and before the server hello done record.
Yep, correct. I outline a DHE KX in this twitter thread: twitter.com/ed_pracnet/status/1618272854667309058
I'll DEFINITELY be rewatching this! Also, great way to incentivize yourself to finish up TLS 1.3 👍😁 Can't wait for that!
=)
holy fuck this blew my mind as to how easy it was to understand it
Anything can be easy if it's explained well. Glad you enjoyed this video =)
Thanks for this video. I have a question related to session keys generation. How Master Secret, Client and server random and "key expansion" are used or combined in order to generate these 4 session keys? My second question is how Master secret is actually generated? You said we combine Pre-Master secret, client and server random and "Master Secret" but what mechanism or algorithm is used to generate it?
Thanks much for the free video.
Wow. What a great video. I definitely learned something new today about SSL keys
This vide is awesome 💯 just having a little doubt from where did that key expansion field come which is been used for the formation of the session keys
so RSA only here for key exchange? no encryption other than symmetric keys? is it then that the symmetric cipher comes into play with the keys to encrypt the payloads?
is the hashing of handshake determined by cipher suite selecion for example SHA1?
Correct. RSA just facilitates the key exchange, and signatures. It doesn't do any real encryption of data sent being client and server.
Yes, hashing is determined by Cipher Suite selection.
Excellent work. Thank you.
Great course! Very well explained. Thanks!
OMG THANK YOU SO MUCH, I NEEDED THIS. Not sure many made it as clear and detailed as that.
Glad this helped =). Please feel free to share it if you know others that might also benefit from this.
This explanation was absolutely amazing! Thank you so much!
You're welcome, Arvind !
I was so shocked about all the things that are being done behind the scenes when you access an https website that I'm thinking that I would be exhausted and do not want to exchange data anymore after that long handshake haha
I just wanted to say thank you for your amazing tutorial on TLS/SSL. I really appreciate the time and effort you put into making such a comprehensive and informative guide.
Any videos doing a similar walk through but with Diffiehellman key exchange? Specifically on and where in the flow the client verifies that the server does possess the long term private key that corresponds with the earlier served x509 cert? Because it doesn't need to send a premaster secret like RSA where is this same validation check performed with Diffiehellman? Ex 11:10
Great question! I don't have a video answer but the pinned post on my Twitter is exactly what you asked for: a walk through of the TLS handshake using diffie hellman as a key exchange. =)
Ed... please refer the video @11.26...what if the middleman sends server his own pre-master-key encrypted using server's public key. I guess server's public key is available to everyone. In this case, how does the server ensure's that the pre-master-key (encrypted with server's public key) it receives is from the actual client and not from someone else. BTW thanks for the video Ed.
excellent description, thank you!
You're very welcome, Christos!
Great course Ed! I have a question on the Cipher Suites used (trying to go through the comments if it was asked before, but can't seem to find it, therefore I apologize for asking "again"). In TLS1.3, all RSA encryption and RSA cipher suites have been removed. The video started by Client having TLS1.3, but did not mention TLS1.2 libraries as well. Is it assumed in this course that Client and Server have both 1.2 and 1.3 for this handshake to work for this course?
did you upload the video for the packet capture of tls handshake that you said here ???
Great video. For @17.00 - Can you please help clarify if the client encryption key gets generated individually at the client and the server? If so, client and server have the same set of 4 pieces of information (Master Secret, key expansion, Client Random, Server Random) that is used for the random hash function. But how is it guaranteed that the random hash function returns the same value both at the client and the server?
The nature of Hashing is that if the Client and Server hash the same pieces of information, they will receive the same output. That is what is happening here, and how the encryption keys calculated by both Client and Server end up being identical.
@@PracticalNetworking To Clarify this further, does this mean that the Client keys are generated using the client random number and the server keys are using the server random number to be generated? otherwise how can you make two sets of keys individually on each host and ensure both sets are the same?
Gunna be using this for my brown bag report at work, big thanks for the save!
One of the best explanation
Highly knowledgeable content!
At 5:56, the slide says Session Id in the Server Hello is 8 bytes / 32 bits? Is that right? Aren't 8 bytes 64 bits?
Yea, that's totally a typo. Someone mentioned this in my discord as well. It should say any range in 0-32 bytes.
In reality, there is one field "Session ID Length" which is always 1 byte (8 bits, values 0-255, of which only 0-32 are valid) which indicates how long the actual "Session ID" field will be.
does tcp handshake (sync, syn-ack, ack ) happen before this ssl/tls handshake when a user visits a website
Yes, typically. There is a version of TLS over UDP that doesn't involve TCP 3 way handshake, but generally most TLS does.
I have some videos on TCP here : pracnet.net/tcp
Could you help clarify what's been explain at 14:40? The concept of two tunnels. Up until that point you've been saying that the keys both the client and the server have are identical. But you go into how TLS creates two tunnels and they are encrypted with two different pair of keys, and that even if one of the tunnel's been comprised, the attacker can only decrypt that tunnel and not the other. How does that work? Aren't both set of keys the same?
I think I may have understood it. BOTH the CLIENT and SERVER generates a SEED for it's respective tunnels that BOTH perform a RSA Key exchange for. Correct me if I'm wrong.
Awesome! Thanks man. Great stuff.
Perfect explanation, thanks!
Always high quality content. Thanks!
Thank you so much for this series.
Thanks for such an informative video.
Glad you enjoyed it =)
Q: If a client initiates TLS 1.0 to a server and gets denied, will it open a new stream to renegotiate the higher TLS with the server or will it use the same quintuple stream on renegotiation?
How long does this to-and-back TLS handshake procedure take ?
Hello Ed, When you are going to add this course on Udemy?
A very good lullaby!
Great content😊😇.. But, .I stucked in some points.. What is exactly "masterkey" inside the "pre-master key". And then "servers finished".? Is that same value both side?
"pre-master-key" is a random value generated by the client (at least, with the version of the handshake illustrated in the video).
This random value is combined with other values to create the "Master Secret".
Which is then combined with yet other values, such as the literal string "Server Finished", to create the actual Session Keys
Thanks😊..
Thanks for the informative video.
YOu're welcome, Morteza!
Why do we need to generate master secret from pre-master secret + client random + server random? Why can't a client generate a master secret right away and encrypt it with server's pub key?
Thank you so much! your video really helped alot. can you make video related to DNS management as well?
My question is client send lists of cipher suite to server. What mechanism is work on server side and server choice one of cipher suite that client send in hello message
Thanks a lot Ed! I have a query regarding slowness issue between two servers (these servers residing in DC and branch office and communicating via meraki vpn) this issue occuring after upgrading our gear to meraki not sure what's the issue here could you help me with some troubleshooting steps please
Thanks in advance
That seems pretty involved, much more involved than what is appropriate for RUclips comments. You can try to ask in discord (pracnet.net/discord) but the issue is borderline something that would require hiring a consultant (which, I'm available for, if you are interested).
@@PracticalNetworking thank you for the reply Ed! It indeed need consultant view will have a word with my manager on this and get back to you thank you again
Simply great!
Is it possible for you to make small introduction video on web3?
Web3 is on my list to cover, at some point. But a lot is in front of it =/
This is awesome!
Wow thank you so much that really helped
Glad you enjoyed it =)
U better live 100 more years ❤️❤️
=)
Fantastic !!! work
This is amazing, but people... why can't we just trust each other!
Wouldn't that be much easier ;)
Awesome...thanks alot
Awesome content. Session Id 8 bytes or 64 bit. Just typo I guess
Yes, it's a typo, good catch =). I clarify it in the TLS 1.3 handshake lesson in the course.
Love the content
Best of best!
Great content