Perfect Forward Secrecy
Vložit
- čas přidán 24. 04. 2017
- John outlines the concept of Perfect Forward Secrecy and describes what it takes to achieve this level of security.
Related links:
community.f5.com/s/question/0...
support.f5.com/csp/article/K1...
techdocs.f5.com/en-us/bigip-1... - Věda a technologie
So simple and lucid explanation, hats off to the presenter.
glad you enjoyed it!
5 years after making this video, it is still totally relevant. Thank you!
Glad it was helpful! And, thanks for the comment!!
Your videos are honestly a joy to watch. Thanks for them :)
glad you enjoy them!
Amazing work! A very comprehensive analysis yet still simple enough for a non technical person (like me lol!) to understand. Ty!
glad you enjoyed it!
Excellent. love the way the concept was simplified and presented.
glad you enjoyed it!
Just one correction/comment here: Diffie Hellman key exchange algorithm is beautifully simple.
Well done, what a fantastic explanation by a great communicator. Good stuff John, thanks!
Glad you enjoyed it!
This is amazing information. THANKS!!!
glad you enjoyed it!
WOW, that was amazing. Thank you.
glad you enjoyed it!
Wow, helps me a lot for the preparation to my crypto-exams. Thanks
glad you found it helpful!
dc you are terrific! Real good stuff.
glad you enjoy the videos!
Awesome video. I think it would be great if this also included examples of when exactly the keys are regenerated, as I had to find this information on my own. One example is when an IPsec connection's key lifetime expires: the security association (SA) is re-established and a new key generated.
Great suggestion! Appreciate the comment!
Hey F5 thanks for the video. I got one confusion. From the DH video client sends "few, guessed" key exchanges with first hello message eliminating extra back and forth. But in this video, first client waits for server to send prime, mod, A.
This video is pure gold
Glad you enjoyed it and thanks for the comment!!
Good video thank you, doesn't the prime number and modulo with generated A gets sent from client to server, instead of server to client
Hello John.
I'm tasked with setting up a vpn for a use case and your videos have been extremely helpful in understanding all the basic stuff that I need for my task, so firstly I wanna than you for that!
One thing that I have not yet grasped is the difference between "Forward Secrecy" and "Perfect Forward Secrecy".
Some sources use the term interchangeably, but I don't think this is true; So the key lies between the DH and EDH for deciding if it's "Perfect" or not.
I am pretty sure it has to do with when the DH pair values are dropped and new are issued.
In DH does the server store those values in hard disc or memory and use the same for each new session for a fixed period of time (set by the server configuration), and in EDH the server is forced to issue new pair values (mod and prime) for each new session with each client?
In DH if the server's pair values are compromised isn't it the same as losing a private key? How is it forward secrecy if the server stores the pair values forever and reuse the same keys.
Again thank you very much for your tutorials and I hope I don't ask for too much.
Have a great day and looking forward for an answer!
those terms are somewhat interchangeable: en.wikipedia.org/wiki/Forward_secrecy
Hi, awesome explanation!
The only thing I don´t get is the difference between the commonly used asymmetric encryption and forward secrecy. You say that in the first case private key is necessary to be used but not in the second one - so that if the first server is compromised and private key exposed, attacker would be able to read all communication. But isn´t it the same in case of forward secrecy? If someone compromised the server, he would be able to gather server´s prime number, modulo, random integer and client´s output - and that is exactly what private key consists of, isn´t it?
Hi Vojta...thanks for the question! Forward secrecy is an effect that is achieved by using an asymmetric encryption algorithm for key exchange that doesn't require the server's private RSA key. If/when you use RSA for key exchange, the server will be using its private key to ultimately generate the symmetric key used for bulk encryption. If this private key were to ever be compromised, an attacker could take it and easily generate the symmetric key used for bulk encryption. Then, the attacker could decrypt all the information sent between user and server. But, if another type of asymmetric encryption is used for key exchange (by the way, asymmetric encryption is always used for key exchange...it just depends on which asymmetric encryption algorithm you want to use), then you can get around the issue of using the server's private key for generating the symmetric bulk encryption key. By far, the most popular asymmetric key exchange algorithm that does not require the server's private key is the Diffie Hellman key exchange algorithm. When using Diffie Hellman, a new random integer is created for every client/server session and this integer is used to generate the symmetric encryption key for bulk encryption. When the client and server establish a new session, a new integer is generated and that integer is used in creating the new symmetric key for bulk encryption. By doing this, the server's private RSA key is never part of the calculation. So, if the server's private RSA key is ever compromised, the attacker would not be able to use it to then generate the symmetric key used for bulk encryption. I hope this helps...let me know if you have any other questions about this!
F5 DevCentral Hi thx for the vid and explanation. A follow up question, in the case of perfect secret forward or DH key exchange, the server never needs to use its private key. Isn’t this make it possible for anybody to impersonate the server if one acquires the sever’s public certificate? I mean all the server or any pretend server needs to do is passing the certificate to the client. Assuming the certificate is not expired, the client should accept it. Could u plz elaborate on this ? Thank you.
@@keke8273 i also have this same question. i gone through some of the materials related to PFS and my understanding is, Private key is only used for server identification and there after private key plays no role in bulk encryption. DH cipher takes the role of creating new keys for every session and it does the bulk encryption & so private key has no role to play in this. Even if private key is compromised, the encrypted data cannot be decrypted using the private key.
This will be my response to your question. If you have gotten some clarity on this PFS flow, please let me know.
Correct me if I'm wrong but during the Diffie-Hellman's key exchange isn't the server supposed to pick a cyclic mod-N group ( modulo ) so it can pick a generator (primitive root) of that said group? Then server and client would have to pick a coprime in the multiplicative group of integers which is not really RANDOM like you explained in the video, I might be wrong af tho
Let's assume modulo is N, generator is g, coprimes are a and b. Don't forget that N and g are public:
Server would: g^a(mod-N) = A to encrypt just like in RSA
Client then: g^b(mod-N) = B
Both then sends each other A and B
Server compute: B^a(mod-N)
Client compute: A^b(mod-N)
Both should arrive at a common secret "key".
Just one doubt: Isn't the prime number used as a modulus in the DHE algorithm? There is another small integer used here as a base. The formula should be A = (base_num^server_secret_num MOD prime_num). The base_num, prime_num, and A are sent to the client-side. Similarly, B = (base_num^client_secret_num MOD prime_num) is sent to the server by client. The next calculations on each side generates a common number which is used as a secret key: (A^client_secret_num MOD prime_num) = (B^server_secret_num MOD prime_num). Please correct me if I'm wrong.
Awesome analysis 👍👍👍👍
glad you enjoyed it!
Hey John, how does the server decides on the cipher suite? Does an admin configure priority at the F5 level or if there is an algorithm? Thanks
Great question! The web server admin will set up a priority list of cipher suites and configure that on the server (in this case, the F5 BIG-IP). When the client requests the HTTPS page, the client will also provide a list of cipher suites configured on the client (browser). Then, the server will look at the client list and then pick the one that fits the server list the best. So, in the end, the server gets to make the decision on which cipher suite is chosen. Here's a document that goes into more detail on how to configure the server cipher suites on the BIG-IP: support.f5.com/csp/article/K01770517
Am I the only one who is impressed by his ability to write mirrored characters?
Are you joking? :D
the whole video is mirrored on top of that. thats why everyone on this channel is writing with his left hand
John mentioned in the video for some links but I couldn't see them appreciate if you could share them again if done already. Thanks.
Sorry about the lack of links...it's updated now. Here they are:
devcentral.f5.com/s/question/0D51T00006i7Y2m/enabling-pfs
support.f5.com/csp/article/K15194
techdocs.f5.com/en-us/bigip-15-0-0/big-ip-ltm-configuring-custom-cipher-string-for-ssl-negotiation/configuring-a-custom-cipher-string-for-ssl-negotiation.html
great explanation, so where do we see PFS application often beside on webservers ?
Thanks KJ! Anywhere you configure TLS ciphers (mostly on webservers, as you noted), you can utilize PFS ciphers.
The explanaation was so great. But one question still, If an eaves dropper can here all P,g,A and B values, he can compute the outputs, as you have mentioned, if it's even a very big prime number the same computation is requeired for the client and the server as well. I am sorry if I am wrong in some way.
Hi leela, great question! As you mentioned, an eavesdropper could have access to many of these values, but the critical part that keeps all of this secret is that the random integers created by each of the server and the client are kept secret. So, the client has its own secret random integer and the server has its own secret random integer. Then they share other values with each other that are based on their own respective secret integers (and the prime, and modulo, etc). The prime and modulo and shared values are all known values to any eavesdropper. But, the client/server random integers are kept secret. Based on all these values, each of the client and server can calculate a new, shared secret value that only they know. The key part is that they need all the known, shared values, but they also need their own secret integer value in order to calculate the shared secret value. An eavesdropper won't have the secret values from the client/server, so he wouldn't be able to calculate the overall shared secret value. I hope this helps!
@@devcentral Thanks you v much for your explanation. Great explanation sir.
This is great. Encryption can be gnarly. Simple question - what constitutes a "session" with a server? Is it each request for a web page? Does it start at first contact with a server and end when a browser is closed?
Hi Michael...this is a great question! A "session" is typically defined as "a group of user interactions with your website that take place within a given time frame". So, this could mean that a user visits your website and looks at several different pages or maybe adds something to a shopping cart or posts a comment, etc. Session times can be configured by each website administrator, so there are no definite mandates that force a session to be a certain length of time. That said, many sessions default to a 30 minute timeframe. This means that when a user visits a website and then has 30 minutes of inactivity, the session will end. You might see this from time to time with bank or credit card websites where they prompt you to see if you are still there visiting the site. Here's a page that outlines how Google Analytics tracks web sessions: support.google.com/analytics/answer/2731565?hl=en
I hope this helps!
That's perfect. Always wondered about that. Thanks.
So the first method you explained wherein the decryption of pre-master secret by server's private key is how RSA key exchange algorithm works ?
I think what needs some clarification here is how the Diffie Hellman key exchange derived key gives rise to the parameters used in other algorithms used for encrypting data, such as RSA or AES... a single secret key (especially one that isnt even prime) isnt a good starting point for communicating the parameters for other algorithms.
Great video. Thank you
Thanks and we appreciate the comment!!
hi, good explanation!
i am looking for some worth ideas to research in. for professional academic research , regarding authentication , PFS ,... if any?
Where can i find the list of cipher suite Support (PFS) ?
Well explained. Thank you 🙏
Glad it was helpful!
brilliant video, keep it up
glad you enjoyed it!
Correct me if i am wrong
But this method is more vulnerable to man in the middle attack. Instead using certificates to exchange pre-master secret key is a better option always.
Hi Aditya...thanks for the question! The exchange of the pre-master secret will be done using one of two primary methods...either RSA or Diffie Hellman. So, the question becomes...which one is better? Most people today would claim that the Diffie Hellman method is superior because it offers "forward secrecy" whereas RSA does not. As for a man-in-the-middle attack, both of these are potentially susceptible to that attack, but one is not inherently better than the other. The solution for the man-in-the-middle attack is to verify/authenticate the server you are communicating with. To do this, a series of authentication mechanisms like digital signatures and hash algorithms are used in conjunction with the server certificate. All these things are used together to make sure data stays secure. I hope this helps!
If we were to depend on DHE algorithm to arrive at the common secret and skip through the key exchange how do we verify the authenticity of the server the client is talking to. From what I understand in case of Public key infrastructure, the certificates are signed by the common CA, and thus we can validate that the server we are talking to is a legitimate one and not an imposter.
_DHE_ will be used to derive the *symmetric key.*
_SSL/TLS_ cert can still be used for *authenticity.*
It's all good & stuff, except that most big company IT people hate PFS since it prevents them from doing their traffic/packet inspection.
To an extent true, you just have to be a participant in the TLS key exchange such as a proxy. If thats not possible, most orgs disable ECDHE at the LB (on the backend) and then allow the remaining appliances/tech to do the inspection on a trusted network.
Does ephemeral DH have any disadvantages compare to RSA that RSA still is being used in TLS handshake?
Hi Nick...great question! Compared to RSA, DH doesn't really have any disadvantages. RSA has definitely been used around the world for many years, so it will take a while to phase it out, but DH is steadily being used to replace RSA. When using RSA, you can share the server's private key with other security devices to allow them to decrypt the data and inspect it before it hits the web server. But honestly that's not really an advantage as much as it is an architecture design approach...many organizations are moving away from that because it requires sharing private keys with other devices, and that could lead to the theft or disclosure of the private key. I hope this helps!
Why dont client and server both just broadcast out their static public keys every time they try to connect somewhere, and use their private keys to resolve the data?
John : Doesn't DH Ephemeral key exchange result in more over head and consumes more CPU on big ip ?
@abhijith ks, yes it does. however, you can use elliptic curve DH and the overhead cost goes down considerably. so, when possible, prefer ECDHE ciphers. and, as @Blood Sausage mentioned, you can also crypto offload the key exchange to specialized hardware...that will significantly help as well. thanks!
Good input, any idea how I get the Cavium type used? Is that the Octeon or Neuron processor family that F5 uses from Cavium?
I have a question, why can't client use a "ephemeral" private key for the RSA public key system? What's the disadvantage of that? It seems from your explanation by using ephemeral client private keys it achieves the same results as Diffie-Hellman PFS.
When RSA was designed, it was never set up to use ephemeral private keys. The fundamental way it is designed does not allow for it. This is why it is so important to secure the private key when using RSA...if anyone gained access to it, they could decrypt all the information used by its encryption.
If I understand this correctly, it keeps the random integers for the C and S completely private (never sent out), but the prime number and modulo will be sent 'publically'. Now, if someone intercepts the prime number and modulo (man-in-the-middle), it doesn't matter because they still won't know the secret key because they need the private random integers from the C and S to generate this secret key; correct or wrong?
that is correct. the random integers are kept secret, and the prime number and modulo are sent publicly. an attacker would need the random integers in order to compute the secret key. hope this helps!
F5 DevCentral It does, thank you! Is this specific for DH, or all perfect forward secrecy algorithms?
awesome! on the DH thing...honestly, DH is the only widely-used perfect forward secret algorithm out there today. not saying others won't come along and gain popularity, but DH is the one for now!
Cool, thanks for the help and clarity!
no problem...happy to help!
Really good work here. Is he writing everything backwards?
thanks! the writing is actually done forwards and then flipped in post production. glad you enjoyed the video!
F5 DevCentral You guys shoulda just said yes and make him look like an insane genius 😂
@@devcentral Wait does that mean you are wearing a shirt with a logo backwards?!
@@JonasLekevicius who us? ;)
If this is the case with perfect forward secrecy, why isn't DH Ephemeral the default required cipher suite used and all others deprecated ?
Great question! In fact, for the new TLS 1.3 protocol all other cipher suites are deprecated and only DH key exchange is used. Like any other technology, it will take a while for all the older protocols to get phased out, but everything is moving to perfect forward cipher suites!
great video
glad you enjoyed it!
where person is writing ? is this on a glass? how is this annotation works can anyone explain it to me?
So you do not need Private/Public Key when using DH ?
You will still use the RSA public/private key for server authentication but not for key exchange purposes. Thanks!
Nice explanation
glad you enjoyed it!
But does this method allows to authenticate the same client between multiple sessions? It looks to me it's ""only"" good for security? Yes I am noob
great question! if i understand your question correctly, the short answer is "yes". Perfect Forward Secret (PFS) ciphers allow a client to connect to a web server in a secure way. The encryption method creates new keys for each session. So, if one client connects to a web server for one session and then that session ends, and then that same client connects to the same web server again in a new session, new encryption keys would be established for that new session even though it is the same client and web server. I hope this helps!
It seems you missed to explain session ticket. If I use session ticket to reopen my session, it will almost looks like RSA. Cheers
If A and B are transmitted each time and B's secret is compromised then shared secret is computable. Or did I miss something?
I thought a double ratchet was required for it to work
Whats the role of Server certificate in PFS?
Great question Adarsh! The server certificate is just used for server authentication in PFS. So, the encryption keys are shared using PFS ciphers, but the server identity is validated using the server certificate. It basically validates that the client is actually talking to the correct server and not some other bad server that is acting like the legitimate server. Hope this helps!
@@devcentral but what do we gain then from PFS if the only problem was that someone can steal the private key of a server? The same problem still exists: someone could steal server's private key, so the certificate also
@@mbesida Great question! The thing that you gain with PFS is that the server's private key is never used to calculate the symmetric key used for encryption during the session. It is true that the server's private key is used to show that the server is who you think it is, but as for encrypting the data sent to/from the client/server during the session...the server's private key is never used for generating that encryption key. So, if someone were to steal the server's private key then they would not be able to decrypt all the data sent to/from the client/server during that session. I hope this helps!
@@devcentral well, nothing prevents the intruder to terminate all TLS sessions to make clients to establish them again. So new symmetric keys will be generated by intruder and clients will not suspect any problems
Diffie Helman _Key Exchange_
❤❤
how is the secret generated on the client side?
Replied with this on another question from you, but here it is again, just in case...thanks!
Different software applications will handle this differently, but the outcome will be the same regardless of which application is used (Diffie Hellman keys will be generated). As an example, Microsoft uses function calls to a Cryptographic API that will generate the key values. Here's some documentation on how they do it: docs.microsoft.com/en-us/windows/win32/seccrypto/diffie-hellman-keys#generating-diffie-hellman-keys
That's awesome
Glad you liked it! We appreciate the comment!
So the private keys are good only for certificate signing in and thats about it
Oops now i remember, the recpient private key and the sender ephemeral public key is used for decryption
lol NY resolution - ephemeral joke
great
glad you enjoyed it!
This is prone to MITM attacks. I think the public part of server is signed
Hi Sameer, you are correct that Diffie-Hellman can be susceptible to man-in-the-middle attacks. The purpose of this video was to discuss Perfect Forward Secrecy and how it works. That's not to say there aren't issues related with key exchange algorithms. But, to be fair, there are issues with RSA as well. Regardless, the industry is definitely moving the direction of DH for key exchange (TLS 1.3 will be exclusively DH for key exchange). I appreciate the comment, and it's always good to know the pros and cons of any implementation. Thanks!
But DF is prone to man in the middle
Hi Dalphaguy, you are correct that Diffie-Hellman can be susceptible to man-in-the-middle attacks. The purpose of this video was to discuss Perfect Forward Secrecy and how it works. That's not to say there aren't issues related with key exchange algorithms. But, to be fair, there are issues with RSA as well. Regardless, the industry is definitely moving the direction of DH for key exchange (TLS 1.3 will be exclusively DH for key exchange). I appreciate the comment, and it's always good to know the pros and cons of any implementation. Thanks!
Ephemeral=New year resolution 😂
IS HE WRITING BACKWARDS?!?
you can see Behind the Scenes for Lightboard Lessons here: czcams.com/video/U7E_L4wCPTc/video.html
i really need to understand how you're writing backwards without breaking your brain
Thanks for your comment! One of our top questions for sure. Here's how we produce these: czcams.com/video/U7E_L4wCPTc/video.html