Transport Layer Security, TLS 1.2 and 1.3 (Explained by Example)
ฝัง
- เผยแพร่เมื่อ 30 พ.ค. 2024
- TLS which stands for transport layer security is a protocol for securing communication between client and server. Specifically for HTTPS. Thats what the S is stands for.
In this video, we will learnq how insecure vanilla HTTP works, HTTPS, then we will learn how HTTPS is possible via the transport layer security and finally we will talk about the improvements in 1.3 that was published August 2018.
Chapters
0:00 Intro
1:30 Vanilla HTTP
5:00 HTTPS
8:35 TLS 1.2
14:30 Diffie-Hellman
17:55 TLS 1.3
Vanilla HTTP
HTTPS
TLS 1.2 handshake
TLS 1.3 enhancements
Vanilla HTTP
Before we discuss TLS, HTTPS or anything else lets go through how HTTP request work. You can type in the browser www.husseinnasser.com , the OSI magic kicks in, client figures out the IP address of husseinnasser.com by calling the DNS which uses UDP. Then HTTP application layer makes a GET / request passes in the IP address and port 80 (default for insecure http). This creates an underlying TCP connection. GET / string among other stuff into the packet and send it over. TCP does its thing server receives GET / calls the appropriate process at the backend which could be just return index.html sets content type text/html and sends back big response for client. All of this obviously is plain text no encryption any kind and if you watched the OSI video we made you can tell that people can sniff/snoop packets and get packets they aren’t supposed to get
HTTPS
Works by negotiating a symmetric key so they can both secure messages. Watch the video we did on encryption. Before we jump to GET request there must be a handshake 🤝 that must occur between the client and server. The tricky part is exchanging that key. Same thing as above except port is 443 instead of 80. Remember once we lose the TCP connection we will have to renegotiate the key. But beauty of this is HTTP is stateless so it remains working just fine.
Tls handshake 🤝
The original TLS handshake involves 4 roundtrips. A client hello which the client includes which encryption algorithms it supports (Both symmteric and asymmetric). The server receives the request then replies back with the server certificate which includes the server public key and also the encryptions that they will change to. The client receives the server hello, generates the premaster key, encrypts it with the server’s public key then send it over. The Server decrypts the message, gets the premaster generates the symmetric key finally tells the client that we are good to go.
Tls 1.3
TLS 1.3 involves much shorter and much secure communication using only deffie hellman as key exchange and just two round trips.
More Resources
www.cloudflare.com/learning-r...
blog.cloudflare.com/rfc-8446-...
🏭 Software Architecture Videos
• Software Architecture
💾 Database Engineering Videos
• Database Engineering
🛰 Network Engineering Videos
• Network Engineering
🏰 Load Balancing and Proxies Videos
• Proxies
🐘 Postgres Videos
• PostgresSQL
🧮 Programming Pattern Videos
• Programming Patterns
🛡 Web Security Videos
• Web Security
🦠 HTTP Videos
• HTTP
🐍 Python Videos
• Python by Example
🔆 Javascript Videos
• Javascript by Example
Stay Awesome!
Hussein - วิทยาศาสตร์และเทคโนโลยี
Dude i cant even try to explain how much I'm learning from you. These long videos are amazing. Thank you! Please never stop.
🙏🙏
He's never gonna do that, I believe on our amazing mentor.
Absolute gem. It is not easy to explain so many tough and technical concepts in under 25 minutes. Thank you for sharing and teaching!
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.
really appreciate the time and effort you put behind these videos. Thank you so much for sharing your knowledge !
Hey, yesterday only i started watching your channel, almost watched 6 to 7 videos, you are doing awesome job.
Very neat way of explaining . I will remember the diagrams for a very long time
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
Flexing my membership emojis lol
Just found your channel the other day and did not hesitate to become a member. Already binge watched several videos. Thanks Hussein!
I think you can become the the best prof ever, trust me, you are making a heavy impact in the community of developers helping us developers grow with quality content
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!
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
th-cam.com/video/zSQtyW_ywZc/w-d-xo.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
@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 TH-cam.
Thanks! haha nicely done I see what you did there
@@hnasr Seriously man, I implemented TLS1.2 in IBM-TRIRIGA but I didn't know the basics in the way you delivered here. Hats Off!
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 th-cam.com/users/timedtext_video?ref=share&v=AlE5X1NlHgg
@@hnasr
Well I don't really know if their is a marked for it.
If you're taking a Web-Developer education in Denmark, then all of your books and lectures are in English anyways.
But if it will make you happy, then I'll be glad to give back in some way.
And who knows, maybe it's good for SEO, The Algorithm, Karma or something else.
i like how you explain complex concepts with simple words and drawings..., i did enjoy this video, subscribed.
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
Great explanation, thank you very much for the presentation and graphics! The point starts from 5:27
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 th-cam.com/video/64geP_LAZ5U/w-d-xo.html
Thanks Hussein. All your explanations make these complexities easy to grasp.
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.
haha I loved the way you wrapped it together! it was fun to watch
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 th-cam.com/video/r1nJT63BFQ0/w-d-xo.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!
Thanks for the long videos, they need to be long. I am loving it.
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😁👍
Hi! great video, from my understanding there is one part missing regarding SSL and it's interaction with the exchange:
Client generates Priv key (CKpriv)
Client generates a random key (RK)
Client generates a public key using RK and CKpriv to make (CKpub)
Client sends CKpub and RK to the server
Server has SSL keys for pub and priv that can undo each other (SSL-pub) & (SSL-priv)
Server generates priv key (SKpriv)
Server combines CKpub and SKpriv to make (Shared-key)
Server combines SKpriv and RK to make (SKpub)
** this is the difference **
Server encrypts SKpub with SSL-priv to create (SSL-SKpub)
server sends back SSL-SKpub and SSL-pub
Client then verifies Server is the server it was expecting by verifying SSL-pub,
Client Once SSL-pub is verified decrypts SSL-SKpub with SSL-pub, resulting in (V-SKpub)
Client then combines V-SKpub and CKpriv to make (Shared-Key)
Yes, this is what I was looking for in the video. "Where is the server's TLS Certificate being sent to the client!". Thanks, your comment covered that part.
You 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 🙏
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.
Great video using pictures. As they say a picture is worth a thousand words. Thank you for making it easier to understand.
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? :-)
Hey Hussein, could you explain why HTTP is stateless even though it relies on a stateful TCP protocol to establish connections?
Does TLS obsolete the use of server certificates or will they still be used and TLS just speeds up the key exchange and decouples it from the certificates?
Great explanation, thanks a lot!
Love your explanations. Great videos!
Thanks 😊 enjoy the content and tell me what should i make next
I'm getting "The underlying connection was closed: An unexpected error occurred on a send." and a think that is something about TLS... any help?
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) ?
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 got my CKAD after learned from your videos about infrastructures and now I am learning backward.. lol
Salute from South Korea.. :D
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 🔐
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.
Thanks so much for this video tutorial.
you just blew my mind!!! specially TLS 1.3...
And BOOM! The lightbulb goes off... THANK YOU!!!
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?
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.
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?
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 sir u explained very well and your way to teach is amazing!
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 ??
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?
You are amazing. This was super useful!
Glad it was helpful!
Good explanation, thank you!
Nice, simple way you explained. Thanks
May be one video on how to present or give a lecture too!!!!!!!!! This is too good and engaging...
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?
Really loved all your video. Keep going
Nice job!Thank you.
Great explanation!
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??
Excellent video on TLS 1.3
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?
THANK YOU SO MUCH amazing explanation !
Where can I see the actual data exchanged and their binary format? Because all tutorials I've seen so far are just overviews, no actual meat.
So with TLS 1.2 the only thing you would have to deal with if you are a hacker would be the SYN ACK stuff the TCP generates (spoofing ot whatever is necessary here?) And that's principally why it is insecure?
dude you are so cool and explain so well haha thanks
Dude, Awesomely Explained!
Pretty sure that encryption occurs in the session layer. Layer 5.
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
Thank you SO MUCH. This is amazing
Thank you very much for your video. One question, in TLS 1.3, how does the client get the blue and pink key?
It does not get from server it generates itself for each session.
Thank you again nice explanation ... Can we see the public - private key which is sent in browser?
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/
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.
Thanks! This is a great video!
Great video, one question. Is elliptic curve diffie hellman possible in TLS 1.2? Or only in TLS 1.3?
You are correct it is possible and when it is the option then TLS 1.2 can actually be perfectly forward (just slow with extra round trip) this is something I learned after making this video..
That being said it has to be configured on the server to use DH explicitly with TLS 1.2 otherwise a weak key exchange might be used . With TLS 1.3 it has to be DH so it is still more secure
Excellent info! Thanks
question: As I see all of this stuff can be done in the client + server and no need for a third party. So why there are companies who provide certs and they get money for that?
Great question!!! So you are absolutely right, the act of just encrypting the channel between the client and server does not require a third party.
However how do you know the server you are communicating with is REALLY the server that you are suppose to be communicate with? I could intercept your communication (MITM) and establish an encrypted session pretending to be the destination server
That is the server (and sometimes even the client) presents a certificate signed by a trusted third party (verisign/digitcert/ and recently free lets encrypt) that proves the identity of the server or the client.
That is why it is always recommended when you visit a site (google.com) you click on the padlock and see who issued the cert and whom is it issued for) Browsers are pretty good at detecting bad certs but its always a good idea especially when your browsing on a public wifi
Hope that helps
@@hnasrOh, thanks a lot, that really helped! I got it right now.
@@hnasr To clarify, it is possible for a server to use TLS 1.3 for encryption while also using a third party certificate for identity verification, correct? It seems to me that the OP's question may have come from the different definitions of "certificate". One definition is "public key", in the context of encryption. Another definition is "identity validation", in the context of third party certificates. Is all this correct?
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!
Great video and effort. Could you share the titles of books you have read which help us to improve the fundamentals.
Awesome video!
This video length and format I would say as well but the length mainly is perfect because at the end of the 24 minutes if you spend about 6 minutes reviewing everything and then you watch the video again one more time you're getting about three times the retention rate
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
Are we right in saying
Standard TLS - 1.2
Enhanced TLS - 1.3
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.
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?
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.
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
Thanks Hussein I do like your videos
Thanks Mohd!
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
th-cam.com/video/r1nJT63BFQ0/w-d-xo.html
@@hnasr thank you very much!
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
What do you mean by merging the public and private key in TLS 1.3 ? is it hashed ?
Hey! No its uses modular operations, watch this video that I referenced in the video if your interesting in the math bits , its just you need to know that its unbreakable th-cam.com/video/Yjrfm_oRO0w/w-d-xo.html
Thank you Hussein, please can you share the science of encryption links.
Nice video. I am not able to find link to video by professor. I searched in description. Would you please post link?
Appreciated for your video. It's valuable. BTW, could you create a real practice example from the start of generating key ( RSA or other key types, algorithm, and so on), self-signed and export for using between both side.
Sure thing I explained it here th-cam.com/video/t0zlO5-NWFU/w-d-xo.html
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 th-cam.com/video/64geP_LAZ5U/w-d-xo.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🙏
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
Hussein is the GOAT!
Where is the implementation of certificate authority?
you just showed the very true world very clearly :)
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.