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!
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 ruclips.net/user/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.
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
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
@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 RUclips.
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😁👍
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 ruclips.net/video/zSQtyW_ywZc/видео.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
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
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!
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 ruclips.net/video/r1nJT63BFQ0/видео.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!
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.
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?
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.
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.
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 ruclips.net/video/r1nJT63BFQ0/видео.html
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.
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??
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
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.
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?
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
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..
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 ??
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).
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) ?
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?
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.
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?
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.
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 ?
They can't get the key because it is being assembled by the two parties and the attacker only have half of it. Watch my other video for more details ruclips.net/video/64geP_LAZ5U/видео.html
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.
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 :)
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?
Yes, it's more secure but asymmetric encryption/decryption is slower than the symmetric encryption/decryption in the performance point of view. If we did perform entier data communication with asymmetric key cryptography, the communication would be much slower. Hence asymmetric key cryptography is only used for the key exchange and then it uses the symmetric encryption/decryption for data transmission.
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? :-)
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
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!
Hi hussein nassar I have to call a soap web service the client told me that it requires 2way tls and he gave me only vu a certificate tha I imported in windows cert store the client told me that the certificate has been installed on the server. Do you know how can I test the communication? With gg chrome or soap ui? Thanks in advanxe Ayyoub
Hussein Nasser hi Hussein thanks for your replay, I don't see any example with tls option? Is authentification mandatory when the communication uses TLS? If you have a sample example I woul appreciate, since my knowledge with WS and TLS are limited. All I want to do is calling this web service that needs tls and I have the certificate installed on the client machine and the server , I call it with http request on blue prism. But before I try to do it with blue prism I wanted to test if the ws and the communication is working ( on soap ui or other tool..)
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 ruclips.net/video/r1nJT63BFQ0/видео.html ruclips.net/video/x_I6Qc35PuQ/видео.html
It depends on the TLS client, during TLS hello the client says here are the versions I support, version is 1.1, 1.2, Lets say server supports 1.2 and 1.3 .. the server than picks the maximum version it supports and the client supports and goes with that (1.2 in this case) So no you can’t connect to a TLS 1.2 with TLS 1.1 versions must match
In TLS 1.2 the middle man can get hold of server public key. Getting hold of server private key is the only point of failure in TLS 1.2. In TLS 1.3 though, the middle man can get hold of (Server private + Public) and (Client private + Public). He needs to get either Client private key or Server private key to combine it with what he has to generate the symmetric key! Now the points of failure is two. Hasn't it just become easier to break TLS 1.3 than 1.2 since you only need either of the private keys? Sorry if my understanding is wrong, help me know what I missed?
No you are right and good observation, both TLS 1.2 and TLS 1.3 can be MITM as you clearly explained (both are not easy to carry out). Also remember that in both TLS the attacker must present their certificate to the client and here the client must validate the cert (in our case the browser we click on the padlock and verify that the cert is issued by the server) that is why certificate authority is very critical to the TLS. TLS 1.3 is faster and more secure than 1.2 and it is more secure in case in other scenarios not MITM.
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
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?
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/
@@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
How symmetric keys are exchanged in HTTPS? I see that in TLS 1.2 they are exchanged, by encrypting with the public key present in the certificate and i thought the same happens in HTTPS also, but your video doesn't explains how symmetric keys were exchanged in HTTPS
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
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.
Read RFC.
Absolute gem. It is not easy to explain so many tough and technical concepts in under 25 minutes. Thank you for sharing and teaching!
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!
really appreciate the time and effort you put behind these videos. Thank you so much for sharing your knowledge !
Thanks for the long videos, they need to be long. I am loving it.
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.
Very neat way of explaining . I will remember the diagrams for a very long time
Hey, yesterday only i started watching your channel, almost watched 6 to 7 videos, you are doing awesome job.
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 ruclips.net/user/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.
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
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
Great video using pictures. As they say a picture is worth a thousand words. Thank you for making it easier to understand.
Hussein, just wanna say thank you for the video. You helped me understand tls in general. Thank you!
I got my CKAD after learned from your videos about infrastructures and now I am learning backward.. lol
Salute from South Korea.. :D
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 ruclips.net/video/64geP_LAZ5U/видео.html
@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 RUclips.
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!
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
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😁👍
Great explanation, thank you very much for the presentation and graphics! The point starts from 5:27
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
ruclips.net/video/zSQtyW_ywZc/видео.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
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 🙏
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
you just blew my mind!!! specially TLS 1.3...
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!
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?
i like how you explain complex concepts with simple words and drawings..., i did enjoy this video, subscribed.
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 ruclips.net/video/r1nJT63BFQ0/видео.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!
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.
haha I loved the way you wrapped it together! it was fun to watch
And BOOM! The lightbulb goes off... THANK YOU!!!
thanks for this! love the humour you add to the videos
The server hello, is not the certificate. That happens right next.
Спасибо!
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?
Really cool stuff. TLS 1.3 explanation is so succinct.
Really loved all your video. Keep going
Dude, Awesomely Explained!
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.
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.
May be one video on how to present or give a lecture too!!!!!!!!! This is too good and engaging...
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?
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 🔐
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
ruclips.net/video/r1nJT63BFQ0/видео.html
@@hnasr thank you very much!
Thank you again nice explanation ... Can we see the public - private key which is sent in browser?
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.
You are amazing. This was super useful!
Glad it was helpful!
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??
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?
THANK YOU SO MUCH amazing explanation !
thank you sir u explained very well and your way to teach is amazing!
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.
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?
Pretty sure that encryption occurs in the session layer. Layer 5.
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.
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..
I have Chinese Quantum computers. Enjoy your Diffie-Hellman.
you just showed the very true world very clearly :)
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 ??
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).
Nice, simple way you explained. Thanks
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) ?
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?
Great video and effort. Could you share the titles of books you have read which help us to improve the fundamentals.
Nice video. I am not able to find link to video by professor. I searched in description. Would you please post link?
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.
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?
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.
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 ?
Thank you SO MUCH. This is amazing
Thanks so much for this video tutorial.
What OSI layer level is running TLS on ?
What if middleman gets that key during the handshake part? Then he will be able to decrypt all the data. Is there anything special during handshaking?
They can't get the key because it is being assembled by the two parties and the attacker only have half of it.
Watch my other video for more details ruclips.net/video/64geP_LAZ5U/видео.html
@@hnasrOh okay, got your point. Thanks a lot for a quick reply. You are doing a great work for the community. I love watching your videos🙏
Where is the implementation of certificate authority?
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.
Love your explanations. Great videos!
Thanks 😊 enjoy the content and tell me what should i make next
For those interested in more details on TLS I made another video here ruclips.net/video/64geP_LAZ5U/видео.html
How to configure TLS 1.2 version in Arista SW...?...is anyone knows.... Thanks
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 all
Is anyone can help me here if i disable TLS 1.0 and enable TLS 1.1 and 1.2 then my crystal reports is not working
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?
Why TLS not using asymmetric encryption, it is more secure then symmetric right ?
Yes, it's more secure but asymmetric encryption/decryption is slower than the symmetric encryption/decryption in the performance point of view. If we did perform entier data communication with asymmetric key cryptography, the communication would be much slower. Hence asymmetric key cryptography is only used for the key exchange and then it uses the symmetric encryption/decryption for data transmission.
Too much informative and funnny learning statregeay
Excellent video on TLS 1.3
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? :-)
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
Very nice explanation
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!
Hi hussein nassar
I have to call a soap web service the client told me that it requires 2way tls and he gave me only vu a certificate tha I imported in windows cert store the client told me that the certificate has been installed on the server.
Do you know how can I test the communication? With gg chrome or soap ui?
Thanks in advanxe
Ayyoub
Hey Ayyob
You can use CURL with TLS option
stackoverflow.com/questions/12222607/how-to-do-a-soap-wsdl-web-services-call-from-the-command-line
Hussein Nasser hi Hussein thanks for your replay, I don't see any example with tls option?
Is authentification mandatory when the communication uses TLS?
If you have a sample example I woul appreciate, since my knowledge with WS and TLS are limited.
All I want to do is calling this web service that needs tls and I have the certificate installed on the client machine and the server , I call it with http request on blue prism.
But before I try to do it with blue prism I wanted to test if the ws and the communication is working ( on soap ui or other tool..)
dude you are so cool and explain so well haha thanks
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
ruclips.net/video/r1nJT63BFQ0/видео.html
ruclips.net/video/x_I6Qc35PuQ/видео.html
Why http listen port 80 if isp block port 80 can we live website.
Is tls backward compatible? Clients from Tlsv1.1 or less can connect Server Tlsv1.2 ?
It depends on the TLS client, during TLS hello the client says here are the versions I support, version is 1.1, 1.2,
Lets say server supports 1.2 and 1.3 .. the server than picks the maximum version it supports and the client supports and goes with that (1.2 in this case)
So no you can’t connect to a TLS 1.2 with TLS 1.1 versions must match
@@hnasr thank you .. it clear my doubt...
Are we right in saying
Standard TLS - 1.2
Enhanced TLS - 1.3
In TLS 1.2 the middle man can get hold of server public key. Getting hold of server private key is the only point of failure in TLS 1.2. In TLS 1.3 though, the middle man can get hold of (Server private + Public) and (Client private + Public). He needs to get either Client private key or Server private key to combine it with what he has to generate the symmetric key! Now the points of failure is two. Hasn't it just become easier to break TLS 1.3 than 1.2 since you only need either of the private keys? Sorry if my understanding is wrong, help me know what I missed?
No you are right and good observation, both TLS 1.2 and TLS 1.3 can be MITM as you clearly explained (both are not easy to carry out). Also remember that in both TLS the attacker must present their certificate to the client and here the client must validate the cert (in our case the browser we click on the padlock and verify that the cert is issued by the server) that is why certificate authority is very critical to the TLS.
TLS 1.3 is faster and more secure than 1.2 and it is more secure in case in other scenarios not MITM.
@@hnasr Yeah this is my understanding too. Thanks for the reply. It was a clear video and well put. Appreciated
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
Great explanation, thanks a lot!
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?
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/
Sir Nasser but I read TLS 1.2 uses ECDHE_RSA does TLS 1.2 also uses Diffe Hellman?
ECDHE is elliptic curve diffe hellman same concept but slightly different algo it uses smaller key size so its more secure and more efficient
@@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
Very good video, but I think you stated 2-RTT for handshake when you want to say 1-RTT in TLS 1.3.
Hey Hussein, could you explain why HTTP is stateless even though it relies on a stateful TCP protocol to establish connections?
How symmetric keys are exchanged in HTTPS? I see that in TLS 1.2 they are exchanged, by encrypting with the public key present in the certificate and i thought the same happens in HTTPS also, but your video doesn't explains how symmetric keys were exchanged in HTTPS
Harsh Gupta HTTPS uses TLS for secure communication. So yes HTTPS exchange symmetric key as well exactly the same as in TLS.