Just finished my Web-Developer Bachelor Degree. For the final exam 7 presentation, and the one I got was on this subjekt. Luckily I had transcribed this video, translated it into Danish, screen captured the images for my 20 minuets PowerPoint presentation. I got a *B+* (No kidding). So I just wanted to thank you a million times for that, you are the best resource on this topic 👏
Acedia DeKay that is awesome Acedia!! Congrats! Can you update the CC for Danish in the video? I think I enabled community contributions .. here is the channel ua-cam.com/users/timedtext_video?ref=share&v=AlE5X1NlHgg
@@hnasr Well I don't really know if their is a marked for it. If you're taking a Web-Developer education in Denmark, then all of your books and lectures are in English anyways. But if it will make you happy, then I'll be glad to give back in some way. And who knows, maybe it's good for SEO, The Algorithm, Karma or something else.
@Hussein Nasser, You're the best teacher I ever had. I love your videos. Keep making these informative videos. It feels like you've put all your knowledge inside these packets that are transferred to me via TLS v1.3 through UA-cam.
Nice video Hussien, but a few corrections. Diffie Hellman was also used in TLS 1.2. The reason for less round trips in 1.3 is because negotiation for key exchange protocol is no longer needed. I also have issues understanding your example relating to security. You mentioned that in TLS 1.2, an adversary is capable of obtaining the server's private key, which the server does not send over the internet. The adversary can then use this key to decrypt the client's encrypted key which he sends over. My question is, if an adversary can obtain the server's private key in 1.2, why can't he also obtain the server's red key in TLS 1.3, since both keys follow the same "protocol" (both keys are private to the server and not sent over communication). Actually, 1.3 removed cryptographic schemes used in 1.2 that are deemed insecure by standards of modern day technology, for example DES was used in 1.2 but abandoned in 1.3 as its key length is vulnerable to brute force attacks, given the capability of modern hardware. Great video nonetheless!
Efun thanks for your comment and it is a great question. The short answer is perfect forward secrecy The problem is using RSA with TLS 1.2 (thanks for correcting me that you can use DH in 1.2) Remember that the RSA private key of the server is fixed and is used for all communications across all clients. So if an attacker recorded the conversations and then obtained the private key they can decrypt past conversations. RSA private key is more likely to get leaked because it is always hot in memory. Thats how heartbleed got it. With DH the private key is ephemeral and will only be used for just one conversation so it is much harder to leak if not impossible (destroyed after each communication) but if the attacker somehow got it they will be able to decrypt one conversation only. Here is the video i made clarifying all this Why anything before TLS 1.3 is BAD - Perfect Forward Secrecy Explained ua-cam.com/video/zSQtyW_ywZc/v-deo.html
TLS 1.3 is more secure because RSA implementations doesn't guarantee perfect forward secrecy or provide with very low encryption grade, thus TLS 1.3 has changed to only support Diffie Helman. - Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. Source : en.wikipedia.org/wiki/Forward_secrecy#Attacks
Flexing my membership emojis lol Just found your channel the other day and did not hesitate to become a member. Already binge watched several videos. Thanks Hussein!
I think you can become the the best prof ever, trust me, you are making a heavy impact in the community of developers helping us developers grow with quality content
Mate you are awesome, for english not being your first language your fluent with your words and a great teacher, i appreciate your knowledge and you being able to share it, had a good laugh at some of your jokes too, good guy, keep it up brother, subscribed and shall be looking for more good information from you
@@hnasr Your absolutely welcome brother, really helped the better understanding i was looking for on the current encryption systems as im currently building a way towards better internet security and was just not sure on afew little things but you cleared them up for me in a way that couldnt have been any easier to understand and i really admire how well you communicate compared to most from your region and its refreshing because alot of you guys know alot about what doesnt get discussed much in depth by most european origins which makes it painful to learn sometimes but your a cool breath of fresh air for passing knowledge across the globe and you deserve to know it, you can definitely go far in the youtube alleys giving out the right advice to the right people and monatizing on it im sure of it and im glad i made your morning brother, i noticed some salty comments after i posted and hoped this would balance the negativity so im glad to hear it did and i hope you have an awesome day ahead and i look forward to gettin more out of your channel and take care buddy😁👍
this is the best explanation of TLS for me, after watching 4 videos, i can conclude, with this video, i can understand it better. to make it worst, i have no IT background to it. it just so happen i saw tls 1.2 word and i started googling it and have no idea what those professors were talking about. UNTIL THIS VIDEO!
Am a great fan of all your videos, simple way of explaining concepts. Would really appreciate your patience and commitment to learn, prepare and publish these videos.
Sunil Jacob sunil thanks for taking the time to write this message! Im humbled. I try my best to serve the community with what I know. And we all keep learning everyday .. stay safe
guys if you are having trouble understanding this, I would recommend watching khan academy's video and then coming back to this one, you are going to truly appreciate his explanation. @Nasser awesome stuff man
Hey Hussein, I was trying to piece together the TLS handshake and the Certificate roles in HTTPS for the key exchange because I cannot find a video talking about both things and how they complement each other, so for some time I even thought they were somehow mutually exclusive(?). But I think now I got it: So your explanation of DH is what made it clear for me: DH is the protocol used for key exchange, and it does not serve any other purpose. BUT, if we have an IP address and try to do the key agreement for further secure communication, if there's no authentication provided then there could be a man-in-the-middle attack where a 3rd party would negotiate a key with me, another key with the server and basically proxy our messages to each other, changing or keeping what served it best. So we need to know we are really communicating with the server and that's where the authentication comes. So, I believe that the Client Hello is encrypted with the server's public key (which can be found on the certificate) and the server will sign the Server Hello. Is this what happens, or am I missing something? Great video as always. Thank you for the content. Cheers!
Good thinking, thanks for your message! Ever since I made this video i made other videos clarifying each piece and I still learning new stuff everyday .. your questions are valid.. so this is a long comment discussing it in details in TLS 1.2 here is what happens Client send client hello saying I want to establish secure communication, lets us exchange the key and cipher, here is what I support as key exchange algorithm , here is what I support as a symmetric key algorithm (this is called a cipher suite) . The client hello is unencrypted since we don't have the symmetric key Server says cool! I see you support these ciphers lets pick DH as key exchange and AES as symmetric key, here is my part of DH key (the colored keys) here is also my certificate. Server hello is also unencrypted since we still don't have the symmetric key. Clients says sure! server I see you sent me this certificate lets verify that its really you by checking the certificate authority and parent certs (I talked about this here ua-cam.com/video/r1nJT63BFQ0/v-deo.html) Ok I now trust you, here is my portion of the DH I now have the key (server DH params + mine) I now have the key now I will send a change cipher spec message . This one is now partially encrypted (DH params are not encrypted but the rest of the message is .. Server receives it, now it has the DH client params, it has now the full key they start communicating TLS 1.3 Client says yo, I want to communicate I support TLS 1.3 so I'm going to make a guess that we are going to communicate with DH so we save a trip, here is my DH client params .. here is what i support cipher wise.. all the jazz.. so we just saved a trip.. client hello is unencrypted Server recevied client hello, agrees that they use DH and chooses a cipher (AES), picks a server DH param, now server has full symmetric key, .. server responds with the certificate (ENCRYPTED) plus the DH server params (unencrypted).. Client receives the message, no body could have sniffed or changed the certificate in the way since its encrypted, client takes server DH compeltes the key, decrypt certificate, reads it and verifies it.. and tells server to start encrypting faster right TLS 1.3 + DOH + ESNI This is what China just banned (I talked about this recently), Client want to connect to the server so it does a DNS query but uses DOH (DNS over HTTPS) and gets the IP address of the server + the public key of the server ..Client sends client hello (Fully encrypted ).. and does everything we did with TLS 1.3 server receives the message, obviously uses the private key to decrypt the message now it just picks up everything, and sends back the message server hello partionally encrypted (certificate) communication is resumed as we discussed in TLS 1.3... ESNI is the encrypted SNI portion which I talked about in another video hope this shed some light on your questions
@@hnasr Thank you for the detailed explanation! It did clear the confusion in my head. I've also watched the certificates video you've linked and I'll be watching the DOH and ESNI ones. Cheers!
Diffie-Hellman is fast and also isn't reliant on a single point of failure (private key), but it is hopelessly defenseless against man-in-the-middle attacks. Can never have best of both the worlds in computer science ever man..
Hi! great video, from my understanding there is one part missing regarding SSL and it's interaction with the exchange: Client generates Priv key (CKpriv) Client generates a random key (RK) Client generates a public key using RK and CKpriv to make (CKpub) Client sends CKpub and RK to the server Server has SSL keys for pub and priv that can undo each other (SSL-pub) & (SSL-priv) Server generates priv key (SKpriv) Server combines CKpub and SKpriv to make (Shared-key) Server combines SKpriv and RK to make (SKpub) ** this is the difference ** Server encrypts SKpub with SSL-priv to create (SSL-SKpub) server sends back SSL-SKpub and SSL-pub Client then verifies Server is the server it was expecting by verifying SSL-pub, Client Once SSL-pub is verified decrypts SSL-SKpub with SSL-pub, resulting in (V-SKpub) Client then combines V-SKpub and CKpriv to make (Shared-Key)
Yes, this is what I was looking for in the video. "Where is the server's TLS Certificate being sent to the client!". Thanks, your comment covered that part.
Good video. The vulnerability of accessing the private key and then the symmeric key is not really about TLS 1.2. V1.1 had some renegotiation issues that 1.2 no longer has. In 1.2 you can still use DH or RSA in the key exchange (configured in the ciphersuite) that the server and client negotiate over. Diffie Hellman Ephemeral (DHE) in the cipher suite is what solves this threat scenario. This is forward secrecy. You leave out how the public key is deemed trustworthy. The certificate is something the client trusts by virtue of having a CA certificate. The server's public key has to be signed by the same CA. Thats what makes a public key a certificate. For mutual TLS, the converse is true. In TLS 1.3 there is perfect forward secrecy. Never can the symmetric key be derived from possessing the private key. Fro developers that USE this it is a great introduction.
I don’t see how 1.3 is more secure. Your argument against 1.2 was if someone gets the servers private key they easily get the golden key from that encrypted message at the start.But if they have that private key they can just as easily combine it with the pink+blue key from the first message to get the golden key as well. So either way stealing the servers private key is game over for both versions. And cracking the encryption some other way without knowledge of any private key should be equally hard unless the way of how the encryption with the golden key is done is fundamentally different. Edit: nvm I just saw your answer to another comment.
Very nice explanation!! Thank you I have one question, what do you mean by client locking the server's public key at 11:32. Does it encrypt the server's public key with the client's private key?
Thank you for this video, good illustrations and great explanations. However I got carried away too often by the anecdotes and the comments. Don't get me wrong, we need anecdotes+jokes to "spice up" an informative video and make it interesting, but in that one I felt that the balance between information/comments isn't optimal as I kept losing track of the explanations.
Alexandre Young thank you so much really appreciate it I need more comments and feedback like this to strive to get better. Totally Agree , i am working hard to get to the point quicker and make the topic fun.. Cheers!
@@hnasr Wow you replied quickly! Super cool that you want to improve. I just took notes from your video and it took me 2 hours to understand everything! You still succeeded in explaining everything in under 25 minutes, keep it up!
Good video however I don't understand how TLS 1.3 is more secure if the eavesdropper has either the private key of the server or the private key of the user he would be able to get the final key correct? doesn't that make it two points of failure instead of one in TLS 1.2?
Did they really start using Diffie-Hellman in TLS 1.3 just because someone could steal the private key from the server in TLS/1.2? Isn’t that kind of difficult? Or are there other reasons I’m missing? 🤔 Heartbleed :)
Hi Hussein. Just a small question. How can server send back red key, pink key back. You said no one can break blue, pink key pair. All answers are welcomed. Please do write if you know the answer.
Thanks for the really nice explanation. One question though : at 13:30 you mentioned , an access to server private key can be problematic since anyone with that key can decode the secret key. In the new algorithm, client key + public key is passed, with the same logic of access to server private key then the golden key can also be created. Isnt ? I am not sure if this oversimplying of problem.
Check out my udemy Introduction to Database Engineering course database.husseinnasser.com Learn the fundamentals of database systems to understand and build performant backend apps
Excellent one Nasser. This has addressed all my doubts around this topic. On a different note, I have very serious security problem with one of my public apis for which I could not find solution around. Is there a way we can connect on it Nasser?
24:19 you say that RSA is insecure because people were able to pull the private key from the server. Well this could happen with the Diffe-Hellman as well where the hacker is able to get the private key and the D-H parameter, will it make DH algorithm insecure as well? While I agree with the fact that DH requires less hand shakes than RSA, but the point of insecurity of RSA algo seems unreasonable
I was particularly referring to the perfect forward secrecy. using RSA private to perform handshake will expose all communications. (Old and new) once the private key is leaked. Because the same key is used With DH, the key is ephemeral and changed with each session so sure if the attacker managed to get the key they will only be able to get that session buts its very very hard. Obviously Im not saying RSA is bad, Im seeing the static use of key to do the handhake is not a good idea. RSA is used in digital signature and secure when 2048 and larger.
@@hnasr Yes understood, after commenting this question, I went on reading other comments. I saw other people had same doubts and you have answered the same thing previously. Thanks, for answering again. I would suggest to pin the answer to this doubt, as many people point out the same thing.
Hi Hussein, your videos are of great source of learning, thanks a lot, it would be even better if you could create a blog of the video and share the link by this way it would be way comfortable for people like me to read than to watch
I really enjoy your video's. I have a question that you may have had many times before... what do you use for the effect on your mouse? Or is it a wacom pen that you use? Even then... how do you do it? :-)
Hi Hussain, just wondering if you share something on intercepted proxy. In my current org they use the same. Whenever I make any bank connection via chrome I could see the certificate says intercepted proxy. I think it is for any connection I make. What are they and what kind of info my org is getting.Are they see my credentials.
I don't understand one thing about TLS 1.3. What prevents someone from mocking the server and generating red key (now the symmetric key is established)? So now mocked server can decrypt anything that client sends to this mocked server. It was not problem in TLS 1.2, because mocked server didn't have private key. I must not understand something.
You are on the right path but you missed something. In order for the “red” key to be generated the server MUST provide its own certificate that proves that it is indeed the server. The attacker might be able to intercept and generate the red key but they cannot fake the server certificate since it require a CA to sign for it. That uses private / public key to do the signiture. When the client receives the red key it also verifies the certificate and signature and make sure its indeed its talking to the server Watch my video on certificates it might help clarify that ua-cam.com/video/r1nJT63BFQ0/v-deo.html ua-cam.com/video/x_I6Qc35PuQ/v-deo.html
Good question ! Actually The server doesnt have the blue key and doesnt need it. It just needs the blue and pink together so it can combine it with its key (red) so it gets the golden key
So, if we keep certificate above rest APIs, even in TLS1.3 for every request extra 2 rounds of data transfer is needed to obtain symmetrical key. Right?
how the server ensure security of red key, can't it be generated by some random third party and get hand of the (blue+pink) key and generate the golden key??
i just wanted to know about osi model and you keep saying in middle of video to watch some other video in order to grasp this one correctly i have 9 tabs of your videos open rn
Sir, rigth now im using metabase to make connection between metabase and our server. But, unfortunately the connection from the metabase is interrupted, here is an error message from the metabase : The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]". do you know this problem?
There is something I do not understand: You said about TLS 1.2 in 12:03 "If someone got this (symetric key) ... they just decrypted the whole thing" Is it just the same for TLS 1.3? If someone got the generated symetric key (pub key + private key + pub key) ?
Appreciated for your video. It's valuable. BTW, could you create a real practice example from the start of generating key ( RSA or other key types, algorithm, and so on), self-signed and export for using between both side.
I just read that you are from Bahrain! I guess living in California is probably the same climate but with more booze! Also, you know the pointer that you use in your videos? It reminds me of when a Simpsons character is nervous and darting his/her eyes back and forth. I wanted to tell you that! Glen
It only happens once for every session and those generated keys are used only for that session. Example when you establish a connection to google.com that connection is encrypted with set of keys and the moment your browser establishes another connection you need a new TLS session. And yes certificates are exchanged at that stage. I made a video here ua-cam.com/video/r1nJT63BFQ0/v-deo.html
You should process the audio signal of the video, pass it by a compressor, it will make your voice sound much more clearer and professional, there are online tools to compress the audio files.
TLS 1.2 - 1.2 used RSA to exchange symmetric key (encrypting the symmetric key with the server's public key) Takes 2 round trips Client has to get the public key of the server Client uses public key to encrypt symmetric key TLS 1.3 1.3 uses Diffie Hellman Key Exchange to exchange symmetric key Takes 1 round trip only
Nice explanation. TLS 1.2 also vulnerable to CCS attack. So still we are using that. how ? What is secure consideration their following? Answer please.
R K an excellent question, When I researched this video I came across the CCS attack (Change Cipher Spec on 14:32) My understanding that it was a bug in the openSSL library that is used to do the TLS handshake. Basically the attack is when you are able to do the a MITM attack right after the server hello and before the ChangeCipherSpec (CCS) message and instead send an early CCS message to the client, the client will begin encryption before the keys are generated (so the encryption will start with NULL keys) and when you do the attacker can easily predict the keys in this case and use null keys and decrypt communication .. this can only happen on TLS 1.2 as you mentioned and specific version of OpenSSL . Not sure if the bug was ever fixed. But regardless TLS 1.2 has a lot of problems that I discuss in the video... Tls 1.3 doesn’t seem to have this because its i think its just one round trip instead of two plus it forces the use of ephemeral DH. Hope that helps! So yeah we need to switch to TLS 1.2 whenever possible, check your certificates all the time.. I found a source details here the CCS bug : www.tenable.com/plugins/nessus/74326 Hope that helps! Excellent question Cheers
Dear one suggestion for you. Your not telling about film story. You had good knowledge and explanation, but way of telling is not good to have. I saw video multiple times for understanding.
R K thank you for your feedback. I did this video as a higher level software engineering video so My apology if its not as detailed as a network engineer would have liked it to be. appreciate your comment again! I will try to do better
Dude i cant even try to explain how much I'm learning from you. These long videos are amazing. Thank you! Please never stop.
🙏🙏
He's never gonna do that, I believe on our amazing mentor.
Absolute gem. It is not easy to explain so many tough and technical concepts in under 25 minutes. Thank you for sharing and teaching!
Very neat way of explaining . I will remember the diagrams for a very long time
really appreciate the time and effort you put behind these videos. Thank you so much for sharing your knowledge !
HTTP - 1:30
HTTPS - 5:10
TLS 1.2 - 8:35
Diffie Hellman Key Exchange Algorithm - 14:30
TLS 1.3 - 17:55
good
@@rfyiamcool4878 thank you , video has so many unwanted content. which could have been skipped.
@@anuragsom09 That's his style, noone is perfect. He is cool and out of the box.
Thanks Hussein. All your explanations make these complexities easy to grasp.
Thanks for the long videos, they need to be long. I am loving it.
Hussein, just wanna say thank you for the video. You helped me understand tls in general. Thank you!
I love it. Struggled with understanding of Diffie Hellman at first but I got it in the end.
Awesome! If you ever want to see the math behind it, I just made a short digestible video here ua-cam.com/video/64geP_LAZ5U/v-deo.html
Just finished my Web-Developer Bachelor Degree.
For the final exam 7 presentation, and the one I got was on this subjekt. Luckily I had transcribed this video, translated it into Danish, screen captured the images for my 20 minuets PowerPoint presentation. I got a *B+* (No kidding).
So I just wanted to thank you a million times for that, you are the best resource on this topic 👏
Acedia DeKay that is awesome Acedia!! Congrats! Can you update the CC for Danish in the video? I think I enabled community contributions ..
here is the channel ua-cam.com/users/timedtext_video?ref=share&v=AlE5X1NlHgg
@@hnasr
Well I don't really know if their is a marked for it.
If you're taking a Web-Developer education in Denmark, then all of your books and lectures are in English anyways.
But if it will make you happy, then I'll be glad to give back in some way.
And who knows, maybe it's good for SEO, The Algorithm, Karma or something else.
Great video using pictures. As they say a picture is worth a thousand words. Thank you for making it easier to understand.
Hey, yesterday only i started watching your channel, almost watched 6 to 7 videos, you are doing awesome job.
What an explanation that was!
Simply incredible....keep up the good work. Appreciated. Thank you for this.
Mazdad Anklesaria thanks Mazdad! Glad enjoyed this video, will do! cheers
you just blew my mind!!! specially TLS 1.3...
I got my CKAD after learned from your videos about infrastructures and now I am learning backward.. lol
Salute from South Korea.. :D
@Hussein Nasser, You're the best teacher I ever had. I love your videos. Keep making these informative videos. It feels like you've put all your knowledge inside these packets that are transferred to me via TLS v1.3 through UA-cam.
Thanks! haha nicely done I see what you did there
@@hnasr Seriously man, I implemented TLS1.2 in IBM-TRIRIGA but I didn't know the basics in the way you delivered here. Hats Off!
And BOOM! The lightbulb goes off... THANK YOU!!!
i like how you explain complex concepts with simple words and drawings..., i did enjoy this video, subscribed.
Nice video Hussien, but a few corrections.
Diffie Hellman was also used in TLS 1.2. The reason for less round trips in 1.3 is because negotiation for key exchange protocol is no longer needed.
I also have issues understanding your example relating to security. You mentioned that in TLS 1.2, an adversary is capable of obtaining the server's private key, which the server does not send over the internet. The adversary can then use this key to decrypt the client's encrypted key which he sends over. My question is, if an adversary can obtain the server's private key in 1.2, why can't he also obtain the server's red key in TLS 1.3, since both keys follow the same "protocol" (both keys are private to the server and not sent over communication). Actually, 1.3 removed cryptographic schemes used in 1.2 that are deemed insecure by standards of modern day technology, for example DES was used in 1.2 but abandoned in 1.3 as its key length is vulnerable to brute force attacks, given the capability of modern hardware.
Great video nonetheless!
Efun thanks for your comment and it is a great question. The short answer is perfect forward secrecy
The problem is using RSA with TLS 1.2 (thanks for correcting me that you can use DH in 1.2)
Remember that the RSA private key of the server is fixed and is used for all communications across all clients. So if an attacker recorded the conversations and then obtained the private key they can decrypt past conversations. RSA private key is more likely to get leaked because it is always hot in memory. Thats how heartbleed got it.
With DH the private key is ephemeral and will only be used for just one conversation so it is much harder to leak if not impossible (destroyed after each communication) but if the attacker somehow got it they will be able to decrypt one conversation only.
Here is the video i made clarifying all this
Why anything before TLS 1.3 is BAD - Perfect Forward Secrecy Explained
ua-cam.com/video/zSQtyW_ywZc/v-deo.html
TLS 1.3 is more secure because RSA implementations doesn't guarantee perfect forward secrecy or provide with very low encryption grade, thus TLS 1.3 has changed to only support Diffie Helman.
- Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.
Source : en.wikipedia.org/wiki/Forward_secrecy#Attacks
Great explanation, thank you very much for the presentation and graphics! The point starts from 5:27
Flexing my membership emojis lol
Just found your channel the other day and did not hesitate to become a member. Already binge watched several videos. Thanks Hussein!
You really save a computer science student who almost know nothing about TLS but her teacher insists on doing a related project!
All the best on your project 🙏
Really loved all your video. Keep going
I think you can become the the best prof ever, trust me, you are making a heavy impact in the community of developers helping us developers grow with quality content
Very good video on DH key exchange process and of course TLS 1.3. Thanks Nasser.
Thanks 🙏 i made a dedicated video on TLS 1.3 covering more details if you are interested 😊
@@hnasr would you mind getting me link?
Mate you are awesome, for english not being your first language your fluent with your words and a great teacher, i appreciate your knowledge and you being able to share it, had a good laugh at some of your jokes too, good guy, keep it up brother, subscribed and shall be looking for more good information from you
I really appreciate you taking the time to write this comment when you didnt have to. Thank you so much! Stay awesome. Made my morning ..
@@hnasr Your absolutely welcome brother, really helped the better understanding i was looking for on the current encryption systems as im currently building a way towards better internet security and was just not sure on afew little things but you cleared them up for me in a way that couldnt have been any easier to understand and i really admire how well you communicate compared to most from your region and its refreshing because alot of you guys know alot about what doesnt get discussed much in depth by most european origins which makes it painful to learn sometimes but your a cool breath of fresh air for passing knowledge across the globe and you deserve to know it, you can definitely go far in the youtube alleys giving out the right advice to the right people and monatizing on it im sure of it and im glad i made your morning brother, i noticed some salty comments after i posted and hoped this would balance the negativity so im glad to hear it did and i hope you have an awesome day ahead and i look forward to gettin more out of your channel and take care buddy😁👍
this is the best explanation of TLS for me, after watching 4 videos, i can conclude, with this video, i can understand it better. to make it worst, i have no IT background to it. it just so happen i saw tls 1.2 word and i started googling it and have no idea what those professors were talking about. UNTIL THIS VIDEO!
Am a great fan of all your videos, simple way of explaining concepts. Would really appreciate your patience and commitment to learn, prepare and publish these videos.
Sunil Jacob sunil thanks for taking the time to write this message! Im humbled. I try my best to serve the community with what I know. And we all keep learning everyday .. stay safe
@@hnasr Thanks for your kind words. #staysafe
thanks for this! love the humour you add to the videos
The server hello, is not the certificate. That happens right next.
haha I loved the way you wrapped it together! it was fun to watch
you just showed the very true world very clearly :)
Really cool stuff. TLS 1.3 explanation is so succinct.
guys if you are having trouble understanding this, I would recommend watching khan academy's video and then coming back to this one, you are going to truly appreciate his explanation.
@Nasser awesome stuff man
link please?
Hey Hussein, I was trying to piece together the TLS handshake and the Certificate roles in HTTPS for the key exchange because I cannot find a video talking about both things and how they complement each other, so for some time I even thought they were somehow mutually exclusive(?). But I think now I got it:
So your explanation of DH is what made it clear for me: DH is the protocol used for key exchange, and it does not serve any other purpose. BUT, if we have an IP address and try to do the key agreement for further secure communication, if there's no authentication provided then there could be a man-in-the-middle attack where a 3rd party would negotiate a key with me, another key with the server and basically proxy our messages to each other, changing or keeping what served it best. So we need to know we are really communicating with the server and that's where the authentication comes.
So, I believe that the Client Hello is encrypted with the server's public key (which can be found on the certificate) and the server will sign the Server Hello. Is this what happens, or am I missing something?
Great video as always. Thank you for the content.
Cheers!
Good thinking, thanks for your message!
Ever since I made this video i made other videos clarifying each piece and I still learning new stuff everyday .. your questions are valid.. so this is a long comment discussing it in details
in TLS 1.2 here is what happens
Client send client hello saying I want to establish secure communication, lets us exchange the key and cipher, here is what I support as key exchange algorithm , here is what I support as a symmetric key algorithm (this is called a cipher suite) . The client hello is unencrypted since we don't have the symmetric key
Server says cool! I see you support these ciphers lets pick DH as key exchange and AES as symmetric key, here is my part of DH key (the colored keys) here is also my certificate. Server hello is also unencrypted since we still don't have the symmetric key.
Clients says sure! server I see you sent me this certificate lets verify that its really you by checking the certificate authority and parent certs (I talked about this here ua-cam.com/video/r1nJT63BFQ0/v-deo.html) Ok I now trust you, here is my portion of the DH I now have the key (server DH params + mine) I now have the key now I will send a change cipher spec message .
This one is now partially encrypted (DH params are not encrypted but the rest of the message is ..
Server receives it, now it has the DH client params, it has now the full key they start communicating
TLS 1.3
Client says yo, I want to communicate I support TLS 1.3 so I'm going to make a guess that we are going to communicate with DH so we save a trip, here is my DH client params .. here is what i support cipher wise.. all the jazz.. so we just saved a trip.. client hello is unencrypted
Server recevied client hello, agrees that they use DH and chooses a cipher (AES), picks a server DH param, now server has full symmetric key, .. server responds with the certificate (ENCRYPTED) plus the DH server params (unencrypted)..
Client receives the message, no body could have sniffed or changed the certificate in the way since its encrypted, client takes server DH compeltes the key, decrypt certificate, reads it and verifies it.. and tells server to start encrypting faster right
TLS 1.3 + DOH + ESNI
This is what China just banned (I talked about this recently),
Client want to connect to the server so it does a DNS query but uses DOH (DNS over HTTPS) and gets the IP address of the server + the public key of the server ..Client sends client hello (Fully encrypted ).. and does everything we did with TLS 1.3
server receives the message, obviously uses the private key to decrypt the message now it just picks up everything, and sends back the message server hello partionally encrypted (certificate) communication is resumed as we discussed in TLS 1.3... ESNI is the encrypted SNI portion which I talked about in another video
hope this shed some light on your questions
@@hnasr Thank you for the detailed explanation! It did clear the confusion in my head.
I've also watched the certificates video you've linked and I'll be watching the DOH and ESNI ones.
Cheers!
thank you sir u explained very well and your way to teach is amazing!
Dude, Awesomely Explained!
Diffie-Hellman is fast and also isn't reliant on a single point of failure (private key), but it is hopelessly defenseless against man-in-the-middle attacks.
Can never have best of both the worlds in computer science ever man..
THANK YOU SO MUCH amazing explanation !
thank you bro ,i had one defect about tls after this video am very happy gained knowledge about tls , once again thank you broooo
Thank you! This is awesome, knowledge is key 🔐
Nice, simple way you explained. Thanks
Thanks so much for this video tutorial.
Hi! great video, from my understanding there is one part missing regarding SSL and it's interaction with the exchange:
Client generates Priv key (CKpriv)
Client generates a random key (RK)
Client generates a public key using RK and CKpriv to make (CKpub)
Client sends CKpub and RK to the server
Server has SSL keys for pub and priv that can undo each other (SSL-pub) & (SSL-priv)
Server generates priv key (SKpriv)
Server combines CKpub and SKpriv to make (Shared-key)
Server combines SKpriv and RK to make (SKpub)
** this is the difference **
Server encrypts SKpub with SSL-priv to create (SSL-SKpub)
server sends back SSL-SKpub and SSL-pub
Client then verifies Server is the server it was expecting by verifying SSL-pub,
Client Once SSL-pub is verified decrypts SSL-SKpub with SSL-pub, resulting in (V-SKpub)
Client then combines V-SKpub and CKpriv to make (Shared-Key)
Yes, this is what I was looking for in the video. "Where is the server's TLS Certificate being sent to the client!". Thanks, your comment covered that part.
You are amazing. This was super useful!
Glad it was helpful!
Good video. The vulnerability of accessing the private key and then the symmeric key is not really about TLS 1.2. V1.1 had some renegotiation issues that 1.2 no longer has. In 1.2 you can still use DH or RSA in the key exchange (configured in the ciphersuite) that the server and client negotiate over. Diffie Hellman Ephemeral (DHE) in the cipher suite is what solves this threat scenario. This is forward secrecy.
You leave out how the public key is deemed trustworthy. The certificate is something the client trusts by virtue of having a CA certificate. The server's public key has to be signed by the same CA. Thats what makes a public key a certificate. For mutual TLS, the converse is true. In TLS 1.3 there is perfect forward secrecy. Never can the symmetric key be derived from possessing the private key.
Fro developers that USE this it is a great introduction.
Pretty sure that encryption occurs in the session layer. Layer 5.
Thank you SO MUCH. This is amazing
May be one video on how to present or give a lecture too!!!!!!!!! This is too good and engaging...
dude you are so cool and explain so well haha thanks
Love your explanations. Great videos!
Thanks 😊 enjoy the content and tell me what should i make next
I don’t see how 1.3 is more secure. Your argument against 1.2 was if someone gets the servers private key they easily get the golden key from that encrypted message at the start.But if they have that private key they can just as easily combine it with the pink+blue key from the first message to get the golden key as well.
So either way stealing the servers private key is game over for both versions. And cracking the encryption some other way without knowledge of any private key should be equally hard unless the way of how the encryption with the golden key is done is fundamentally different. Edit: nvm I just saw your answer to another comment.
Great explanation, thanks a lot!
Excellent video on TLS 1.3
Very nice explanation!! Thank you
I have one question, what do you mean by client locking the server's public key at 11:32. Does it encrypt the server's public key with the client's private key?
Hussein is the GOAT!
Thank you for this video, good illustrations and great explanations. However I got carried away too often by the anecdotes and the comments. Don't get me wrong, we need anecdotes+jokes to "spice up" an informative video and make it interesting, but in that one I felt that the balance between information/comments isn't optimal as I kept losing track of the explanations.
Alexandre Young thank you so much really appreciate it I need more comments and feedback like this to strive to get better. Totally Agree , i am working hard to get to the point quicker and make the topic fun.. Cheers!
@@hnasr Wow you replied quickly! Super cool that you want to improve.
I just took notes from your video and it took me 2 hours to understand everything! You still succeeded in explaining everything in under 25 minutes, keep it up!
Thank you again nice explanation ... Can we see the public - private key which is sent in browser?
Very nice explanation
Good video however I don't understand how TLS 1.3 is more secure if the eavesdropper has either the private key of the server or the private key of the user he would be able to get the final key correct? doesn't that make it two points of failure instead of one in TLS 1.2?
Excellent info! Thanks
Thanks! This is a great video!
Good explanation, thank you!
Did they really start using Diffie-Hellman in TLS 1.3 just because someone could steal the private key from the server in TLS/1.2? Isn’t that kind of difficult? Or are there other reasons I’m missing? 🤔 Heartbleed :)
Hi Hussein. Just a small question. How can server send back red key, pink key back. You said no one can break blue, pink key pair.
All answers are welcomed. Please do write if you know the answer.
Thanks for the really nice explanation. One question though : at 13:30 you mentioned , an access to server private key can be problematic since anyone with that key can decode the secret key. In the new algorithm, client key + public key is passed, with the same logic of access to server private key then the golden key can also be created. Isnt ? I am not sure if this oversimplying of problem.
Check out my udemy Introduction to Database Engineering course
database.husseinnasser.com
Learn the fundamentals of database systems to understand and build performant backend apps
Thanks Hussein I do like your videos
Thanks Mohd!
Excellent one Nasser. This has addressed all my doubts around this topic. On a different note, I have very serious security problem with one of my public apis for which I could not find solution around. Is there a way we can connect on it Nasser?
Nice video. I am not able to find link to video by professor. I searched in description. Would you please post link?
Great video and effort. Could you share the titles of books you have read which help us to improve the fundamentals.
24:19 you say that RSA is insecure because people were able to pull the private key from the server. Well this could happen with the Diffe-Hellman as well where the hacker is able to get the private key and the D-H parameter, will it make DH algorithm insecure as well? While I agree with the fact that DH requires less hand shakes than RSA, but the point of insecurity of RSA algo seems unreasonable
I was particularly referring to the perfect forward secrecy. using RSA private to perform handshake will expose all communications. (Old and new) once the private key is leaked. Because the same key is used
With DH, the key is ephemeral and changed with each session so sure if the attacker managed to get the key they will only be able to get that session buts its very very hard.
Obviously Im not saying RSA is bad, Im seeing the static use of key to do the handhake is not a good idea. RSA is used in digital signature and secure when 2048 and larger.
@@hnasr Yes understood, after commenting this question, I went on reading other comments. I saw other people had same doubts and you have answered the same thing previously. Thanks, for answering again. I would suggest to pin the answer to this doubt, as many people point out the same thing.
Hi Hussein, your videos are of great source of learning, thanks a lot, it would be even better if you could create a blog of the video and share the link by this way it would be way comfortable for people like me to read than to watch
Great explanation!
21:41, so alladin cannot intercept the chat by taking public+private from client and behave like a middle man here. Like middle-man-attack?
Excellent
I really enjoy your video's.
I have a question that you may have had many times before... what do you use for the effect on your mouse? Or is it a wacom pen that you use? Even then... how do you do it? :-)
very nice thanks
Hi Hussain, just wondering if you share something on intercepted proxy. In my current org they use the same. Whenever I make any bank connection via chrome I could see the certificate says intercepted proxy. I think it is for any connection I make. What are they and what kind of info my org is getting.Are they see my credentials.
Love your video! Keep up the good work!
TLS 1.3 should be a 1-RTT. The diagram is correct but misspelled.
Who comes up with these amazing ideas sometimes the Human Race fascinates me
I don't understand one thing about TLS 1.3. What prevents someone from mocking the server and generating red key (now the symmetric key is established)? So now mocked server can decrypt anything that client sends to this mocked server.
It was not problem in TLS 1.2, because mocked server didn't have private key.
I must not understand something.
You are on the right path but you missed something. In order for the “red” key to be generated the server MUST provide its own certificate that proves that it is indeed the server. The attacker might be able to intercept and generate the red key but they cannot fake the server certificate since it require a CA to sign for it. That uses private / public key to do the signiture.
When the client receives the red key it also verifies the certificate and signature and make sure its indeed its talking to the server
Watch my video on certificates it might help clarify that
ua-cam.com/video/r1nJT63BFQ0/v-deo.html
ua-cam.com/video/x_I6Qc35PuQ/v-deo.html
Awesome video!
18:15 Seinfeld reference "NO SOUP FOR YOU"
If blue and pink keys are unbreakable then how receiving server get the blue key?
Good question ! Actually The server doesnt have the blue key and doesnt need it. It just needs the blue and pink together so it can combine it with its key (red) so it gets the golden key
@@hnasr There is only 2 keys... Why are you talking about 3 keys??? This is wrong and decieving.
So, if we keep certificate above rest APIs, even in TLS1.3 for every request extra 2 rounds of data transfer is needed to obtain symmetrical key. Right?
Very good video, but I think you stated 2-RTT for handshake when you want to say 1-RTT in TLS 1.3.
how the server ensure security of red key, can't it be generated by some random third party and get hand of the (blue+pink) key and generate the golden key??
i just wanted to know about osi model and you keep saying in middle of video to watch some other video in order to grasp this one correctly i have 9 tabs of your videos open rn
Sir, rigth now im using metabase to make connection between metabase and our server. But, unfortunately the connection from the metabase is interrupted, here is an error message from the metabase : The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]".
do you know this problem?
There is something I do not understand:
You said about TLS 1.2 in 12:03 "If someone got this (symetric key) ... they just decrypted the whole thing"
Is it just the same for TLS 1.3? If someone got the generated symetric key (pub key + private key + pub key) ?
Hey Hussein, could you explain why HTTP is stateless even though it relies on a stateful TCP protocol to establish connections?
Appreciated for your video. It's valuable. BTW, could you create a real practice example from the start of generating key ( RSA or other key types, algorithm, and so on), self-signed and export for using between both side.
Sure thing I explained it here ua-cam.com/video/t0zlO5-NWFU/v-deo.html
I just read that you are from Bahrain! I guess living in California is probably the same climate but with more booze!
Also, you know the pointer that you use in your videos? It reminds me of when a Simpsons character is nervous and darting his/her eyes back and forth.
I wanted to tell you that!
Glen
Where is the implementation of certificate authority?
Doe the regeneration of the keys happen with every request with TLS1.3? And do we still speak of certificates?
It only happens once for every session and those generated keys are used only for that session.
Example when you establish a connection to google.com that connection is encrypted with set of keys and the moment your browser establishes another connection you need a new TLS session.
And yes certificates are exchanged at that stage. I made a video here
ua-cam.com/video/r1nJT63BFQ0/v-deo.html
@@hnasr thank you very much!
You should process the audio signal of the video, pass it by a compressor, it will make your voice sound much more clearer and professional, there are online tools to compress the audio files.
Thanks Ricardo, do you have any resources on how to do that? I am using a blue yeti mic and just IMovie for editing
TLS 1.2
- 1.2 used RSA to exchange symmetric key (encrypting the symmetric key with the server's public key)
Takes 2 round trips
Client has to get the public key of the server
Client uses public key to encrypt symmetric key
TLS 1.3
1.3 uses Diffie Hellman Key Exchange to exchange symmetric key
Takes 1 round trip only
Doesn't this make it vulnerable to MITM attacks?
For those interested in more details on TLS I made another video here ua-cam.com/video/64geP_LAZ5U/v-deo.html
nice video
Nice explanation.
TLS 1.2 also vulnerable to CCS attack. So still we are using that.
how ?
What is secure consideration their following?
Answer please.
R K an excellent question, When I researched this video I came across the CCS attack (Change Cipher Spec on 14:32)
My understanding that it was a bug in the openSSL library that is used to do the TLS handshake. Basically the attack is when you are able to do the a MITM attack right after the server hello and before the ChangeCipherSpec (CCS) message and instead send an early CCS message to the client, the client will begin encryption before the keys are generated (so the encryption will start with NULL keys) and when you do the attacker can easily predict the keys in this case and use null keys and decrypt communication .. this can only happen on TLS 1.2 as you mentioned and specific version of OpenSSL . Not sure if the bug was ever fixed. But regardless TLS 1.2 has a lot of problems that I discuss in the video...
Tls 1.3 doesn’t seem to have this because its i think its just one round trip instead of two plus it forces the use of ephemeral DH.
Hope that helps! So yeah we need to switch to TLS 1.2 whenever possible, check your certificates all the time..
I found a source details here the CCS bug : www.tenable.com/plugins/nessus/74326
Hope that helps! Excellent question
Cheers
@@hnasr thanks for your reply.
Dear one suggestion for you. Your not telling about film story. You had good knowledge and explanation, but way of telling is not good to have.
I saw video multiple times for understanding.
R K thank you for your feedback. I did this video as a higher level software engineering video so My apology if its not as detailed as a network engineer would have liked it to be. appreciate your comment again! I will try to do better