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!

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

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

[@stackfulldev]

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

[@gattu26586]

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

[@bama2619]

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

[@vijayredkar6680]

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

[@echovisionlab]

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

[@BalaMurugan-jb5os]

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

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

[@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 🙏

[@shuvo9131]

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

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

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

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

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

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

[@edthom2210]

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

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

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

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

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

[@radiowallofsound]

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

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

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

[@bhushanmulmule7885]

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

[@hnasr]

[@Adele-h2c]

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

[@mrnobody1321]

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

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

[@adityajambhalikar]

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

[@michaelhattenburg6404]

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

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

[@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 🔐

[@ashishmaikhuri3950]

Really loved all your video. Keep going

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

[@rokDh]

Dude, Awesomely Explained!

[@sagarmahajan1756]

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

[@mohamedsalim5905]

Nice, simple way you explained. Thanks

[@joshuasmith8344]

Really cool stuff. TLS 1.3 explanation is so succinct.

[@rahaf7982]

THANK YOU SO MUCH amazing explanation !

[@rusiraliyanage6643]

you just showed the very true world very clearly :)

[@romantsyupryk3009]

Thanks so much for this video tutorial.

[@AriKhuu]

Thank you SO MUCH. This is amazing

[@andrewt580]

You are amazing. This was super useful!

[@hnasr]

Glad it was helpful!

[@hnasr]

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

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

[@usamatahseenulhaque9125]

Very nice explanation

[@ArizuddinGulam]

Excellent video on TLS 1.3

[@YolandisWorld]

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

[@demidrek-heyward]

Hussein is the GOAT!

[@AlaminIslam-hi8dl]

Too much informative and funnny learning statregeay

[@magicandmagik]

dude you are so cool and explain so well haha thanks

[@dirtpipedan]

Love your explanations. Great videos!

[@hnasr]

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

[@gabrieleidler]

Great explanation, thanks a lot!

[@vindikad]

Thanks! This is a great video!

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

[@shashikantpawar7069]

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

[@hnasr]

For those interested in more details on TLS I made another video here kzbin.info/www/bejne/bGXKloOVgaaNa7c

[@shakirhusain]

Good explanation, thank you!

[@mohammadabdraboh3048]

Thanks Hussein I do like your videos

[@hnasr]

Thanks Mohd!

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

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

[@Deekudla]

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

[@Rebasaurusrex]

Great explanation!

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

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

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

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

[@seanlane812]

Awesome video!

[@azharkhuwaja9949]

Excellent

[@rafaelas3916]

Nice job!Thank you.

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

[@jacomojiang4848]

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

[@anshikagupta4931]

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

[@123dfhghfgh45]

Спасибо!

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

[@marvinfollero846]

very nice thanks

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

[@ahmedkhaled7960]

18:15 Seinfeld reference "NO SOUP FOR YOU"

[@prasadcherukuri4687]

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

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

[@tenminutetokyo2643]

You should have mentioned TCP uses sockets for open, close, etc.

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

[@navindudissanayake1669]

Love your video! Keep up the good work!

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

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

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

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

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

[@ashishmaikhuri3950]

This is injustice to TLS 1.3 Please make a good video on it. explaining in details.

[@Sleeperknot]

The way it is presented on the screen would at least make some people think that TLS is something similar to https. Anyone without a fair amount of idea about https is going to find this video very confusing.

[@hnasr]

Agreed! I should have clarified that TLS can be used with other protocols other than HTTPS. Thanks for the feedback Sunil. Cheers

[@Sleeperknot]

Hey by the way are you the same guy in Wd mycloud forum?., I have used your transmission package! Brilliant

[@hnasr]

Sunil TG no I wish I built transmission, its a great software.

[@granand]

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

[@sachinjadhav8759]

nice video

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

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

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

[@zhimingkoh1029]

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

[@yesubabu2880]

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?