on 25-Apr-2017 14:08
Perfect Forward Secrecy allows your encrypted communications to stay secure even if a bad guy were to steal the private key of the websever you were communicating with. But, how is that possible? And, how can a web server be configured to achieve this level of security? In this video, we talk about the concept of Perfect Forward Secrecy, describe how it all works, and then show how you can configure your BIG-IP to make sure you take advantage of this really cool security functionality. Enjoy!
Related Resources:
Hi John,
Thanks a lot for keeping promise 🙂 Great lesson!!
I am a bit puzzled about how client uses it's random integer. You stated that client is using known (provided by server) prime number, modulo and value A to calculate its own value B. If so what client random integer is used for?
If client uses only values that are public (prime number, modulo and value A) - if I am not wrong those are not encrypted, so can be picked up from stored session - then anyone can recreate value B - or I am wrong here?
Next question - what is purpose of generating pre-master secret? In case of RSA it's necessary because only client generates pre-master secret and then sends it to server. But in case of DH both client and server are able to generate the same pre-master after exchanging A and B values, so why not generate master secret skipping pre-master?
I assume that never sending pre-master secret over the wire is the reason why asymmetric encryption is not necessary and DH is safer than RSA?
What is necessary to compromise TLS session in this case - both server and client random integer? Those are only two pieces of info that are never exchanged and if I am right discarded after given session is over?
I am not sure as well what is exact difference between ephemeral and not ephemeral cipher suite. You said that in case of ephemeral for every session new random integers are chosen - so far so good
But what if ephemeral is not used? For given client, server is always using same random integer? Seems a bit unlikely, server would have to store a lot of info (like client to random integer mapping) for a long time.
Is random integer only piece that is changing, so for every client and every session server is using the same prime number and modulo?
Last but not least 🙂 I assume that server is still sending it's certificate so client can verify server identity, only difference is that public key from server certificate is never used for encrypting any piece of exchanged data?
Piotr
Hi Piotr!! Thanks for all the great questions! I'll attempt to answer them all, but if I miss something, please let me know, and I'll follow up with more information.
The random integer is used as a part of the Diffie Hellman key exchange, and the basic idea works like this:
The server comes up with two prime numbers g and p and tells you (client) what they are. You then pick a secret, random number (a), but you don't tell anyone. Instead you (client) compute g^a mod p and send that result back to the server. (We'll call that A since it came from a). The server does the same thing, but we'll call the server's secret, random number b. So the server computes g^b mod p and sends you (client) the result (we'll call it "B") Now, you (client) take the number the server sent you and do the exact same operation with it. So that's B^a mod p. The server does the same operation with the result you (client) sent it, so: A^b mod p.
As it turns out, A^b mod p is the same value as B^a mod p. That's the cool, genius magic behind Diffie Hellman. All of these values can be (and are) sent in cleartext, but no one who might capture them will be able to figure out the value of the final operation because they would need the value a or b to figure it out. And, those values are the secret, random values that the client and server have generated.
As for the ephemeral part, if you don't use ephemeral keys, then the same random values would be used for a longer period of time between a specific client and server. However, if ephemeral keys are used, then the random values are new with every session, so the keys will then change with every session.
Finally, on the server certificate...yes, it's still sent via the RSA algorithm but it's never used for creating keys for bulk data encryption. Rather, like you said, it's only used for server identity purposes.
Thanks again for the great questions!!
Hi,
Thanks a lot for explanation. Now it's clear, as mentioned, in video it looked like client is not using his random key to generate value send to server - it was in contrast with what server did, that's why I was a bit confused. Now it's clear that both server and client uses their random numbers (secrets) to generate values that they exchange 🙂
Thanks again,
Piotr
Sorry, one last question, I know that I am pain in the... 🙂
Why both client and server generate pre-master secret. From description it's never exchanged like in RSA - here it's necessary to allow server generate master key. But for DH seems to be pointless, so why not just generate master key skipping pre-master?
Piotr
I did promise to not ask more questions, but will appreciate if you can answer some more, sorry...
I found this kind of info about ECDHE-RSA
ECDHE suites use elliptic curve diffie-hellman key exchange, where DHE suites use normal diffie-hellman. This exchange is signed with RSA, in the same way in both cases.
The main advantage of ECDHE is that it is significantly faster than DHE.
And I am not sure what exactly does that mean. In case of DH key exchange is based on prime number, modulo and random number. So EC part above means that instead of this method, Elliptic Curve is used in the process that leads to generate pre-master and master key?
Considering RSA part - is that mean that value send by server is signed by server using its X509 private key so client using server certificate can verify if it was not altered on the way (MiM case)?
Last one is about what is the easiest way to match naming convention used by BIG-IP (tmm --clientciphers DEFAULT) to one used by Wireshark.
Let's say in Wireshark I can see TLS_RSA_WITH_AES_256_CBC_SHA (0x0035), on BIG-IP I have a list of ciphers. My guess is that matching entry is:
35: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA
but Am I right?
Convention looks a bit different so hat would be a way to be sure that one matches other?
Piotr
@Piotr, sorry for the delay in answering your questions...but here's my take:
ECDHE and DHE are both "Diffie Hellman" key exchanges. The "E" part, by the way, simply refers to the keys being Ephemeral...or, short lived. That is, a new key is generated for every session rather than using the same one for a long period of time. The primary difference between DH and ECDH is that DH uses a multiplicative group of integers while ECDH uses a multiplicative group of points on an elliptic curve. But, both of these use the Diffie Hellman algorithm to exchange keys. As it turns out, using points on an elliptic curve allows the algorithm to run much faster than using groups of large integers. So, that's why ECDH is much faster than just normal DH. Ultimately, the Diffie Hellman key exchange algorithm leads you to a master key (shared, symmetric key) that is used for bulk encryption. It doesn't matter if you use ECDH or normal DH...either one leads to the shared, symmetric key. Most people prefer ECDH because it's so much faster than normal DH.
The RSA part of all of this is the authentication that you mentioned in your comment. Something has to be used to verify that the server is actually the correct server, and the RSA algorithm is used to do that. One of the confusing parts about all of this is that RSA can also be used for key exchange as well (although, most people don't use RSA for key exchange any more). But, regardless, RSA is used for server authentication.
Last, the naming convention for the cipher suites is best tracked by using the hexadecimal value associated with each suite. I captured a Client Hello and Server Hello for a test web application I have. I'm using BIG-IP v12.0 for this, and I have the DEFAULT cipher suite enabled for my client SSL profile. Here's the Wireshark capture for the Client Hello:
Notice that the browser sends 15 different cipher suites to the server for consideration. Each cipher suite has a hexadecimal value listed to the right of the cipher suite. Keep an eye on cipher suite hex value 0x0039. This will be the one that is ultimately selected by the BIG-IP for this session. Here's the Server Hello Wireshark capture that happened right after the Client Hello:
Notice that the BIG-IP (Server) chose the cipher suite with hexadecimal value 0x0039. The Wireshark capture does a good job of letting you know what's in the cipher suite (TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)), but that doesn't always correspond exactly to the naming convention of the BIG-IP list of cipher suites. Here's a list of the DEFAULT cipher suites on my BIG-IP:
Notice that the naming convention is a little different here. So, in order to correspond the Wireshark list of cipher suites to the BIG-IP list, you should use the hexadecimal value. Unfortunately, the BIG-IP doesn't list the hexadecimal value of the cipher suites by default, but you can cross-reference them using this link: https://support.f5.com/csp/article/K13156. Here's a screenshot of the BIG-IP version 12 cipher suites (notice that the hexadecimal values are listed for each one). And, I circled the 0x0039 so you could track the same cipher suite that was used throughout this session.
I hope this helps! Let me know if you have any other questions!
Hi. thanks for you kind lesson. Recently, my customers want to use PFS. However, to use PFS, we need to use DHE or ECDHE. and the Cipher usually has a lower performance than RSA. In fact, the problem I'm having is: For i-Series, see the datasheet. ECC performance is specified, but existing BIGIP series does not have such data. I have to explain how there is some performance degradation when using Cipher for PFS, but I have difficulty because there is no rough guide. I would really appreciate it if you could help. happy new year
Hi swjo...great question! The specs that F5 provides for SSL TPS is for hardware. As an example, the 12250v has specialized hardware for RSA, but not for ECC. You can still use ECC ciphers in version 11.4+ regardless of hardware platform, but the processing of the ECC ciphers is done in software except on our newer platforms that have ECC-specific hardware. Our new i-Series platforms all have specific hardware for ECC (and they still have hardware for RSA as well). The reason that the other platforms don't list the ECC-specific SSL TPS numbers is that ECC is done in software for those specific platforms and the numbers will vary greatly depending on CPU utilization, etc.
As a point of comparison, the i10800 platform is comparable to the 12250v but it has ECC specific hardware, and it is rated at 48K TPS (using ECDSA P-256). More specifically, it used the ECDHE-ECDSA-AES128-SHA256 cipher string for testing.
I hope this helps.