Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.
share|improve this question
up vote 15 down vote accepted

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).

share|improve this answer
gmail+chrome uses TLS 1.1 ECDHE_RSA with RC4 and SHA1. – CodesInChaos Jun 16 '13 at 17:45
MSIE does not support DHE cipher suites, although it supports some ECDHE cipher suites. – Erwan Legrand Oct 23 '14 at 10:44

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.