Perfect Forward Secrecy in TLS Explained
Вставка
- Опубліковано 7 сер 2024
- Perfect Forward Secrecy is a property of an encryption system that prevents an attacker that from decrypting past recorded sessions even after the private key of the server is leaked.
🏭 Software Architecture Videos
• Software Architecture
💾 Database Engineering Videos
• Database Engineering
🛰 Network Engineering Videos
• Network Engineering
🏰 Load Balancing and Proxies Videos
• Proxies
🐘 Postgres Videos
• PostgresSQL
🚢Docker
• Docker
🧮 Programming Pattern Videos
• Programming Patterns
🛡 Web Security Videos
• Web Security
🦠 HTTP Videos
• HTTP
🐍 Python Videos
• Python by Example
🔆 Javascript Videos
• Javascript by Example
👾Discord Server / discord
Support me on PayPal
bit.ly/33ENps4
Become a Patreon
/ hnasr
Stay Awesome,
Hussein - Наука та технологія
actually this video was needed after tls video, i came here from that video as one user also queried about the same . this is great you are not leaving any point unexplained, you are spirit of real engineer
That is a really decent video mate!
Sad just just a limited audience gets to see it.
Keep going.
This is the best explaination of TLS! Thanks for share!
Love your videos Hussein. Could you do a video about JWT and how claims can be used in general. Thanks!
Great video as always
Great video! thanks
Great videos Hussein, always used to get confused where key exchange comes into picture in tls handshake....very well explained...
Santosh Kodicherla thanks Santosh!!
@@hnasr One request is, video on 0-rtt which is feature in tls1.3. If you can explain that with example. That would be awesome. I see your videos on tls1.3 coming one of top videos when i search for tls1.3 handshake. I am sure lot of people would like that too.
great video with basic details....
could you please share some example with openssl tool
Nice video with good explanation
Very good video, super funny examples ;) Minor detail that's a little off: 8:20 Heartbleed is a buffer over-read bug as you do not write outside the boundaries of a buffer but just read the data.
Great video Nasser.
Also I have a question around this. So basically the difference between 1.2 and 1.3 is that the 1.3 always uses DH whereas in 1.2 it is decided during handshake?
Also the key is ephimeral in 1.3 and in 1.2 the same key is used in multiple sessions? By session do you mean browser session?
If the server key is leaked in 1.3 just as you mentioned for 1.2 cant the sniffer decrypt messages as he can combine it with the pub+private(client) keypair to generate the symmetric key?
Thanks!
Great video Hussein. A small doubt, with TLS1.3 if we are using the public key (certificate), and private key just for Authentication, then can we omit the private key in the server ? Browser only requires SSL certificate to verify if it is signed by CA right ? If I just configure only SSL certificate in my server is it OK ?
2) Consider in future only TLS1.3+ is only going to be supported, then I think there is no need to sign public key by the CA. He can just sign an arbitiary string provided by the client (website owner) and sign it right, as public/private key is never used ?
You still want the private key (of the public key found in the certificate) on the server because it will be needed to prove that server owns that certificate (as the certificate is public - you don't want anyone just copying it onto their server).
Also, generally the server will use that private key to sign a hash of the handshake transcript, to prove nothing has been tampered with along the way. (that's a better approach than just signing an arbitrary string for proof).
Fun and educational video! Why only a limited audience gets to see it? I don't understand.
great video Hussein, thanks :)
Have a question, in TLS 1.2 client1 will share its private key with server with encryption means client1-server will have common key for the entire communication, but if another client client2 makes request to the server than client2-server will have different key for their entire communication which is client2's private key.
in TLS 1.3 also after using Diffie Hellman client and server will have a final key that they both will use for encryption-decryption. but handshake will happen only once right.? if yes then client1-server will use that key for entire communication and when client2 will send request server willl change its private key and client2-server will have a new key which they will use for entire communication.
In both the cases each client-server communication will use same key for entire communication which will be unique to them. Then even if heartbleed happened, attacker won't get private key because it is different for each conversation, if the attacker got private key he can see only one conversation with that key in both the cases.
please correct me if i'm wrong, Thanks :)
In DH-Ephemeral, the long-term public/private key pair is always the same on the server, but is just used for authentication - that is to prove the server really is who they say they (i.e., they own their certificate) during a connection with a new client.
Both client and server will generate their own new private keys for the DH exchange - those only last during the handshake and are used to derive a shared, symmetric key which is then used for all messages going forward.
So the point of Perfect Forward Secrecy (PFS) thru the use of the "E" (Ephemeral) in DHE is to ensure that the compromise of the long-term private key held on the server has no effect on decrypting (presumably saved) conversations, because that long-term private key (for authentication) was NOT used to derive any encryption keys for client-server communcation.
Love the video
First of all your video is perfect for explaining the process for a beginner or a quite well knowledgeable guy. But I would like to dive in a lil deeper. In DHE both parties create a keypair and exchange the public key (which is associate it with the private but not contain the private) but you showed us only private key being held in the server, is that correct??. Also when in the tls 1.3 handshake the variables (g,n for DH, or G for an ECDH) are exchanged, so both parties can use em ( g^a mod n , for DH) or (Q = d*G , for ECDH) in order to end up in the same preshared key?? If it is the user, would not that be bad in a sense of intetionally or not weak DH param being chosen?? If it is the server then how the client end up in a public key without knowing the DH params??
Antonis Misirgis thanks Antonis, you were right your question is deep. My understanding is both client the server generates a private/public key . The client combines the public+private key and sends it (unbreakable combo) the server receives this and adds its private key to the combo to generate the final symmetric key. The server now combines its private key and public key and return it to the client (unbreakable combo) the client now takes that combo and adds its private key to generate the symmetric key.
Thats my understanding hope it makes sense. I am not familiar with the actual math unfortunately behind it.
In TLS 1.3 there are a bunch of pre-negotiated groups for DH (whether finite fields or elliptic curves), and the client would pick one of them - see RFC 7919. Servers aren't allowed to come up with custom ones anymore in 1.3
But having pre-defined (and known to be secure) 'g' and 'p' is fine. The client then just chooses a secret 'a' and the server will choose it's secret 'b'. Client sends A = g^a mod p, Server sends B = g^b mod p. Client calculates S = B^a mod p, which is equal to the server's calculation of S = A^b mod p.
Final shared symmetric key is then basically S (not exactly - but derived easily from it).
The private keys of 'a' and 'b' are completely separate from the long-term private key held on the server (which corresponds to the public key in the certificate). Unfortunately the term 'private key' is overloaded here - one is long-term and used for authentication with every connection, the other is short-term / ephemeral, and is created in order to derive (as shown above) a unique symmetric key for that session's communications.
What is the need for certificates when using Diffie Hellman? Looks like, we are not using the public key from the cert in this operation at all?
Excellent question! The public key in the cert becomes less and less relevant and only used for identity. The server also encrypts the DH parameters in the server hello using its private key for additional security this way the client will use the public key to decrypt the server hello to complete the handshake.
@@hnasr Interesting thing is even if the identity is broken, we dont really care because Diffie Hellman is independent of the cert. Hence we dont really care if someone hijacks the cert which begs the question, why not recieve the cert completely?
To put it differently for TLS handshake, we stop using the cert. Client picks keys, server picks keys. exchange the keys using Diffie Hellman and continue the communication?
No, the certificate is extremely important. Without it, you can do what is called a man in the middle attack.
If an attacker could intercept the packets, they could pretend to be the server and establish a shared key with the client. Then when the client sends a request it would go to the attacker. The attacker then pretends to be a client and establishes another shared key with the real server. And just like that, all messages go through the attacker and he can read every message, even change them.
The server prevents this by signing it's response (step two of the diffie Hellman handshake) with the private key. The attacker doesn't have this key, so he can't provide the client with a valid handshake response. If the "server hello" is not signed/encrypted by the private key, then the entire thing is broken.
To put it another way, it doesn't matter how good your encryption is if you have no way to prove who you are actually talking to.
There are two different public/private key pairs the server deals with during a DHE scenario. One is the ephemeral set, generated at time of connection, used only for the encryption of that session. The other is the long term pair, and is used for authentication: the public key will be in the certificate, and the private key will sign the whole set of handshake messages.
Certificates are still needed because because an encrypted conversation isn't very useful if you don't really know who it is on the other end of your connection.
Edit: Didn't see Andrew's post above mine, oops! He answered this already =)
Thanks!