Transport Layer Security, TLS 1.2 and 1.3 (Explained by Example)

[@belferman]

Dude i cant even try to explain how much I'm learning from you. These long videos are amazing. Thank you! Please never stop.

[@hnasr]

🙏🙏

[@ACHTech20]

He's never gonna do that, I believe on our amazing mentor.

[@pajeetsingh]

Read RFC.

[@robertsedgewick1266]

Absolute gem. It is not easy to explain so many tough and technical concepts in under 25 minutes. Thank you for sharing and teaching!

[@acediadekay3793]

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 👏

[@hnasr]

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 kzbin.info_video?ref=share&v=AlE5X1NlHgg

[@acediadekay3793]

​@@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.

[@rahulramteke3338]

HTTP - 1:30 HTTPS - 5:10 TLS 1.2 - 8:35 Diffie Hellman Key Exchange Algorithm - 14:30 TLS 1.3 - 17:55

[@rfyiamcool4878]

good

[@anuragsom09]

@@rfyiamcool4878 thank you , video has so many unwanted content. which could have been skipped.

[@nirjharjajodia7169]

@@anuragsom09 That's his style, noone is perfect. He is cool and out of the box.

[@yuqiwang7829]

You really save a computer science student who almost know nothing about TLS but her teacher insists on doing a related project!

[@hnasr]

All the best on your project 🙏

[@gattu26586]

Very neat way of explaining . I will remember the diagrams for a very long time

[@echovisionlab]

I got my CKAD after learned from your videos about infrastructures and now I am learning backward.. lol Salute from South Korea.. :D

[@jasomtan8485]

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!

[@joaodias1241]

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!

[@hnasr]

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 kzbin.info/www/bejne/qGLRe4dsaKd5h5I) 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

[@joaodias1241]

@@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!

[@surbhipaliwal879]

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

[@stackfulldev]

really appreciate the time and effort you put behind these videos. Thank you so much for sharing your knowledge !

[@wfenwick]

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.

[@ethan9435]

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!

[@hnasr]

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 kzbin.info/www/bejne/sIS0payNlN6qkMU

[@batmanish]

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

[@dankingswell7082]

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)

[@iprashanthnani]

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.

[@BalaMurugan-jb5os]

Hey, yesterday only i started watching your channel, almost watched 6 to 7 videos, you are doing awesome job.

[@Girry_]

I love it. Struggled with understanding of Diffie Hellman at first but I got it in the end.

[@hnasr]

Awesome! If you ever want to see the math behind it, I just made a short digestible video here kzbin.info/www/bejne/bGXKloOVgaaNa7c

[@patricksantos4199]

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!

[@vijayredkar6680]

Thanks Hussein. All your explanations make these complexities easy to grasp.

[@Hummingbird314]

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.

[@hnasr]

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

[@Hummingbird314]

@@hnasr Thanks for your kind words. #staysafe

[@Bargains20xx]

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

[@abdulmoizsheikh8031]

link please?

[@livesamarth]

@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 KZbin.

[@hnasr]

Thanks! haha nicely done I see what you did there

[@livesamarth]

@@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!

[@adityajambhalikar]

May be one video on how to present or give a lecture too!!!!!!!!! This is too good and engaging...

[@shuvo9131]

Thanks for the long videos, they need to be long. I am loving it.

[@edthom2210]

Great video using pictures. As they say a picture is worth a thousand words. Thank you for making it easier to understand.

[@mrnobody1321]

thanks for this! love the humour you add to the videos The server hello, is not the certificate. That happens right next.

[@offchopsmediaphotography4672]

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]

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

[@offchopsmediaphotography4672]

@@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😁👍

[@bama2619]

Great explanation, thank you very much for the presentation and graphics! The point starts from 5:27

[@mazdadanklesaria8235]

What an explanation that was! Simply incredible....keep up the good work. Appreciated. Thank you for this.

[@hnasr]

Mazdad Anklesaria thanks Mazdad! Glad enjoyed this video, will do! cheers

[@Marwane2323]

i like how you explain complex concepts with simple words and drawings..., i did enjoy this video, subscribed.

[@VivekYadav-ds8oz]

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

[@pajeetsingh]

I have Chinese Quantum computers. Enjoy your Diffie-Hellman.

[@SathonesRaga55]

Very good video on DH key exchange process and of course TLS 1.3. Thanks Nasser.

[@hnasr]

Thanks 🙏 i made a dedicated video on TLS 1.3 covering more details if you are interested 😊

[@SathonesRaga55]

@@hnasr would you mind getting me link?

[@PrSunflower]

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.

[@hnasr]

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!

[@PrSunflower]

@@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!

[@bhushanmulmule7885]

you just blew my mind!!! specially TLS 1.3...

[@hnasr]

[@ahmedayman6170]

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?

[@shashikantpawar7069]

Thank you again nice explanation ... Can we see the public - private key which is sent in browser?

[@Potzakv20]

Doe the regeneration of the keys happen with every request with TLS1.3? And do we still speak of certificates?

[@hnasr]

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 kzbin.info/www/bejne/qGLRe4dsaKd5h5I

[@Potzakv20]

@@hnasr thank you very much!

[@Adele-h2c]

Hussein, just wanna say thank you for the video. You helped me understand tls in general. Thank you!

[@michaelhattenburg6404]

And BOOM! The lightbulb goes off... THANK YOU!!!

[@radiowallofsound]

haha I loved the way you wrapped it together! it was fun to watch

[@srivatsanraman2827]

thank you bro ,i had one defect about tls after this video am very happy gained knowledge about tls , once again thank you broooo

[@hnasr]

Thank you! This is awesome, knowledge is key 🔐

[@kambalavijay6800]

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?

[@ashishmaikhuri3950]

Really loved all your video. Keep going

[@ustoopia]

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

[@Deekudla]

Great video and effort. Could you share the titles of books you have read which help us to improve the fundamentals.

[@mostinho7]

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

[@VivekYadav-ds8oz]

Doesn't this make it vulnerable to MITM attacks?

[@YolandisWorld]

Pretty sure that encryption occurs in the session layer. Layer 5.

[@joshuasmith8344]

Really cool stuff. TLS 1.3 explanation is so succinct.

[@anshikagupta4931]

Who comes up with these amazing ideas sometimes the Human Race fascinates me

[@syedoffice1966]

If blue and pink keys are unbreakable then how receiving server get the blue key?

[@hnasr]

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

[@71GA]

@@hnasr There is only 2 keys... Why are you talking about 3 keys??? This is wrong and decieving.

[@sagarmahajan1756]

thank you sir u explained very well and your way to teach is amazing!

[@IamVarunBhardwaj]

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.

[@mohamedsalim5905]

Nice, simple way you explained. Thanks

[@jshiwam]

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

[@hnasr]

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.

[@jshiwam]

@@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.

[@AlaminIslam-hi8dl]

Too much informative and funnny learning statregeay

[@shaklinsyed6701]

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

[@usamatahseenulhaque9125]

Very nice explanation

[@zhimingkoh1029]

Hey Hussein, could you explain why HTTP is stateless even though it relies on a stateful TCP protocol to establish connections?

[@rusiraliyanage6643]

you just showed the very true world very clearly :)

[@dolphinlunggrin6594]

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.

[@DS-rq8cx]

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.

[@rahaf7982]

THANK YOU SO MUCH amazing explanation !

[@romantsyupryk3009]

Thanks so much for this video tutorial.

[@shefsheko]

in 21:46 TLS1.3 is done in *one*, not two round trips. Great video btw, thanks

[@hnasr]

Sergio Díaz thanks. Correct, It was a slip in my stupid english , appreciate it

[@shefsheko]

@@hnasr your English excellent! And no worries, I really think your content is great!

[@rk.x01]

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.

[@hnasr]

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

[@rk.x01]

@@hnasr thanks for your reply.

[@rk.x01]

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.

[@hnasr]

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

[@GlenMillard]

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

[@ArizuddinGulam]

Excellent video on TLS 1.3

[@mryoussefsonic]

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?

[@rokDh]

Dude, Awesomely Explained!

[@宋考俊]

Thank you very much for your video. One question, in TLS 1.3, how does the client get the blue and pink key?

[@akacademy6903]

It does not get from server it generates itself for each session.

[@2f4uReActiON]

Great video, one question. Is elliptic curve diffie hellman possible in TLS 1.2? Or only in TLS 1.3?

[@hnasr]

You are correct it is possible and when it is the option then TLS 1.2 can actually be perfectly forward (just slow with extra round trip) this is something I learned after making this video..

[@hnasr]

That being said it has to be configured on the server to use DH explicitly with TLS 1.2 otherwise a weak key exchange might be used . With TLS 1.3 it has to be DH so it is still more secure

[@andrewt580]

You are amazing. This was super useful!

[@hnasr]

Glad it was helpful!

[@mohamedsamet4539]

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

[@AriKhuu]

Thank you SO MUCH. This is amazing

[@ricardoalonzo8404]

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.

[@hnasr]

Thanks Ricardo, do you have any resources on how to do that? I am using a blue yeti mic and just IMovie for editing

[@thecyberneh]

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 :)

[@CheaHang]

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.

[@hnasr]

Sure thing I explained it here kzbin.info/www/bejne/qmHdnYJrYrOKfLc

[@AbhishekJha-g2w]

Idk if you're going to reply on this but I do need to know one thing for sure when server can extract the public key from the combination of private key + public key sent by a client why can't Aladin extract those values? if that's possible i think TLS 1.2 is much secure lmao, at least we are not sharing the private key over the networks in TLS 1.2.

[@abhirampemmaraju6339]

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?

[@prasadcherukuri4687]

Nice video. I am not able to find link to video by professor. I searched in description. Would you please post link?

[@jamesmarkchan]

Does TLS obsolete the use of server certificates or will they still be used and TLS just speeds up the key exchange and decouples it from the certificates?

[@bonbonpony]

Where can I see the actual data exchanged and their binary format? Because all tutorials I've seen so far are just overviews, no actual meat.

[@jacomojiang4848]

Very good video, but I think you stated 2-RTT for handshake when you want to say 1-RTT in TLS 1.3.

[@ayex86]

What OSI layer level is running TLS on ?

[@TheGreatDaniad]

question: As I see all of this stuff can be done in the client + server and no need for a third party. So why there are companies who provide certs and they get money for that?

[@hnasr]

Great question!!! So you are absolutely right, the act of just encrypting the channel between the client and server does not require a third party. However how do you know the server you are communicating with is REALLY the server that you are suppose to be communicate with? I could intercept your communication (MITM) and establish an encrypted session pretending to be the destination server That is the server (and sometimes even the client) presents a certificate signed by a trusted third party (verisign/digitcert/ and recently free lets encrypt) that proves the identity of the server or the client. That is why it is always recommended when you visit a site (google.com) you click on the padlock and see who issued the cert and whom is it issued for) Browsers are pretty good at detecting bad certs but its always a good idea especially when your browsing on a public wifi Hope that helps

[@TheGreatDaniad]

@@hnasrOh, thanks a lot, that really helped! I got it right now.

[@michaeldacosta7504]

@@hnasr To clarify, it is possible for a server to use TLS 1.3 for encryption while also using a third party certificate for identity verification, correct? It seems to me that the OP's question may have come from the different definitions of "certificate". One definition is "public key", in the context of encryption. Another definition is "identity validation", in the context of third party certificates. Is all this correct?

[@DarkKnightt28]

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?

[@ragon747]

I'm getting "The underlying connection was closed: An unexpected error occurred on a send." and a think that is something about TLS... any help?

[@biplob2071]

What will happen, If at first exchange Aladin get Blue+Pink and next return exchange Aladin get the Red key? And Jine, Combine Blue+Pink+Red = Create GOLDEN KEY So, Aladin get GOLDEN KEY !!!!! OMG !!! Awesome Explain. Thanks

[@ahmedkhaled7960]

18:15 Seinfeld reference "NO SOUP FOR YOU"

[@sudharajamanickam7534]

if my application uses(for instance online shopping application ) plain tcp protocol for connecting to our partners' hosts who process payments, tcp is not secure way for transmitting data? TLS X.X or SSL will be applicable only for https (Application Layer protocols)? or TLS/SSL its self a protocol which can work on top of TCP? Also, Say for example a payment processor shared http endpoint which is TLS enabled one. and I am connecting it with tcp --- how the encryption/decryption happens at both ends ?

[@iWontFakeIt]

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

[@bipulmishra1543]

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.

[@umeshb8210]

Sir Nasser but I read TLS 1.2 uses ECDHE_RSA does TLS 1.2 also uses Diffe Hellman?

[@hnasr]

ECDHE is elliptic curve diffe hellman same concept but slightly different algo it uses smaller key size so its more secure and more efficient

[@umeshb8210]

@@hnasr ty sir found a documentation which explains wat RSA actually does in ECDHE_RSA thank you again for the great explanation tools.ietf.org/html/rfc4492#section-2 security.stackexchange.com/questions/90090/what-is-the-role-of-rsa-in-ecdhe-rsa

[@alanraftel5033]

I'm a little bit confused, I'm already generating Diffie-Hellman Parameters and using them in my nginx config with TLS 1.2. What's the difference between TLS 1.2 with DH-params and TLS 1.3?

[@hnasr]

Alan Raftel If nginx supports 1.3 Which I think it does I think you should enable it since it will boost your performance by slashing the roundtrips in half as I explained. with 1.2 + DH you will still be doing 2 roundtrips instead of one for 1.3. here is how you enable 1.3 in nginx found this article www.google.com/amp/s/www.howtoforge.com/how-to-enable-tls-13-in-nginx/amp/

[@dirtpipedan]

Love your explanations. Great videos!

[@hnasr]

Thanks 😊 enjoy the content and tell me what should i make next

[@mohammadabdraboh3048]

Thanks Hussein I do like your videos

[@hnasr]

Thanks Mohd!

[@gabrieleidler]

Great explanation, thanks a lot!

[@bhanuprakashrao1460]

In TLS 1.3, how does the client verify if the server is indeed what it says it is? Im TLS 1.2, we verify the servers identity using the server certificate(which contains the public key of the server) that server sent in response + a trusted CA. But how do we do it in TLS 1.3 @Hussein Nasser ??

[@bishooyatif]

Server verification is definitely used in TLS 1.3 also. The server sends its certificate with its deffie-hellman parameters. The certificate is used for authentication not for pre-master key encryption as happens with TLS 1.2 (as the client parameters will be already sent in the first call).

[@granand]

Thank you Hussein, please can you share the science of encryption links.

[@None-l9w]

Are we right in saying Standard TLS - 1.2 Enhanced TLS - 1.3

[@shakirhusain]

Good explanation, thank you!