What should I know before configuring Perfect Forward Secrecy?

Question

PFS has gained attention in our audit department because of its innate ability to limit our exposure if someone steals our private key.

• What pitfalls or common mistakes should I be aware of before implementing this? Anything administrative, implementation-specific, or platform-specific?
• Are there misconceptions regarding what PFS can and can't do? Could our Audit department need a reality check?
• Are the benefits of PFS limited by application? (web vs smtp, etc)

Some of these concerns come from this answer, which seems to imply that not all web clients will support PFS. Prior to making PFS mandatory on our server, I would like to account for and prepare for the incompatibilities.

• Would it be reasonable to expect my OS vendor or load balancer (SSL Offloading) to support reporting of encryption used? I'd like to generate usage statistics.

Answer 1

PFS in SSL implies that the server performs, for each new session, a Diffie-Hellman key exchange and a signature, so the CPU cost of the handshake on the server is about doubled compared to a non-PFS cipher suite. But it is rather infrequent that the handshake CPU cost is non-negligible (clients which open several connections use the abbreviated handshake which uses symmetric cryptography only, and a basic PC has enough power to handle several hundreds of complete handshakes per second with a single CPU core). I suggest making an in-context benchmark.

Still with SSL, there is no defined PFS-able cipher suite which also supports RC4 encryption. Apart from that, all non-archaelogic Web browsers currently deployed will accept the "DHE" cipher suites (which yield PFS) so there is no interoperability issue here; the question is rather whether you want RC4 or not: you have to balance the fear of ulterior key compromise (against which PFS adds some protection) with the fear of chosen-ciphertext attacks (i.e. BEAST, to which RC4 cipher suites seem immune).

The OS or load balancer might report cipher suites statistics, but I would not bet on it. You can make tests with OpenSSL (the command-line executable, with the s_client command). You can also use any decent protocol analyzer like Wireshark, which can tell you which cipher suite is used on a given connection (the cipher suite identifier is sent "in the clear" as part of the initial steps of the handshake, so it is easy to grab it with a sniffer).

Answer 2

Interoperability was an issue in the past, particularly in ipsec. SSL is a little easier, but not all clients support it. If I wanted to check my traffic, I'd probably tcpdump on a span port and write a script to look for the accepted cipher suite in the handshake, assuming we're talking SSL.

Answer 3

What pitfalls or common mistakes should I be aware of before implementing this? Anything administrative, implementation-specific, or platform-specific? A few that spring to mind.

There are two key exchange algorithms used in forward secrecy TLS. DHE and ECDHE. To get forward secrecy with the widest range of clients you need to support both. You should generally preffered ECDHE over DHE because it performs better and for compatibility with Java 7 (see below).

Making forward secrecy mandatory will exclude Internet Explorer (any version) on windows XP. I expect the same will be true of anything that uses the windows built in SSL/TLS stack on XP.

For DHE you need to make sure you use strong dh parameters. You should use custom generated dh parameters with at least a 2048 bit prime (the security of a dh prime is comparable to a RSA key of the same length).

Java 6 and 7 break if you negotiate a DHE ciphersuite and use DH parameters larger than 1024 bit. This is a particulally acutute issue with java 6 as it does not support ECDHE.

Prior to making PFS mandatory on our server, I would like to account for and prepare for the incompatibilities.

One option could be to make the forward secrecy ciphersuites preffered but not mandatory and set up your server to log what ciphersuite is used for each connection. You can then look at your logs and determine how many clients you would lose if you mandated forward secrecy.

Are there misconceptions regarding what PFS can and can't do? Could our Audit department need a reality check?

Basically what forward secrecy does is prevent someone who stole your key using it to passively decrypt traffic. In particular without forward secrecy someone who has been monitoring and storing your traffic and later steals your key can go back and decrypt the traffic they captured previously.

What forward secrecy will not do is prevent someone who stole your key from using it to impersonate you (and either act as a man in the middle or replace your server with theirs).

Forward secrecy will not help you if the symetric encryption is broken. The cryptography used for the forward secrecy key exchange could also potentially be broken (see the comment about above dh parameters).

Are the benefits of PFS limited by application? (web vs smtp, etc)

The benefits are the same but you may well find that support in clients is not as common.