Seven Grades of Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) becomes popular and its adoption rate is growing. An importance of implementing it becomes even more obvious after recent attacks on SSL such as Heartbleed.
In Hartbleed case an impact could have been leveled down if PFS had been implemented by affected parties, since compromising private SSL key would not necessary lead to a possibility of decrypting SSL traffic.
To understand an adoption rate of PFS by different sectors of economy, the first question that we would need to answer is: “What does PFS adoption mean?” It turned out that it’s not a “Yes” or “No” question and should be formulated in terms of maturity rather than in the simple “implemented”/”not implemented” terms.
There are different options that a system engineer can consider when it comes to implementation. They are not only related to security. Usability, performance and compatibility issues must be also considered if an implementer wants to have a solution that everybody will be happy with.
There are newer (ECDHE) and older Diffie-Hellman ciphers (DHE). While the former is based on Elliptic Curves and delivers a better performance, the latter has a wider support by legacy browsers.
Another aspect is related to preferred ciphers, i.e. the ones that are selected by a server when a client provides a big variety of ciphers to chose from and the server needs to decide, which one to use.
By combining two aspects described above, we could come up with the following grades for a PFS implementation:
- Only PFS ciphers are supported. A preferred cipher is an ECDHE.
- Only PFS ciphers are supported. A preferred cipher is an old DHE.
- Both PFS and non-PFS ciphers are supported. A preferred cipher is ECDHE.
- Both PFS and non-PFS ciphers are supported. A preferred cipher is an old DHE.
- ECDHE and DHE ciphers are supported, but a preferred cipher is not ECDHE or DHE.
- DHE is supported, but ECDHE is not. A preferred cipher is not ECDHE or DHE.
- PFS ciphers are not supported.
With this ranking system in place creating a tool that analyses a state of PFS in different industries was easy. The tool assigns a grade to each tested server and calculates a handshake time, which can be compared with that for a non-PFS cipher.
Comparing a handshake time with a non-PFS ciphers can be important, because it allows estimating a possible performance impact.
A report below generated by the tool demonstrates PFS adoption by different sectors of economy. The winning sectors are: Defense, Internet, InfoSec and Education. Big financial institutions (FI) showed poor results and it’s not a surprise – FI’s are probably good in handling privacy, compliance and fraud issues where funding and resources are abundant due regulatory requirements, but when it comes to security innovations they are definitely not a leader.
On contrary, big Internet companies that have been blamed many times for poor privacy policies are doing well in the area of security engineering. No surprises here.
Big software companies that fell to the same bucket as Finance were a surprise and a disappointment. Catching up with big Internet and Defence companies might be a good idea for them.
Finally, an important issue related to perceived “performance impact” of PFS ciphers didn’t show up in the results of this testing. I think, this is because network latency is taking over of any additional overhead added by PFS ciphers. I could see that overhead when a client and a server were running on the same subnet and a handshake time was under 10ms, but for Internet connections where a handshake time grew to over 100ms, the difference between PFS and non-PFS ciphers was negligibly small and inconsistent.
The speed of SSL handshake depends a lot on a physical client and server locations, but is usually ranging from 40 ms to 700 ms. Such a big difference and inconsistency of the handshake time decreases the importance of performance considerations as well.
No tested server made it to a category #1 or #2 and this is probably because implementers wanted to have a reliable non-PFS fall-back options for legacy browsers.
The “Perfect World” category consists of three servers built in different cloud and non-cloud environments to demonstrate that grades #1 and #2 are achievable and sane. All browsers that I had on my Desktops and Laptops could connect to the servers, but testing it with all legacy browsers was beyond the scope of this exercise.
“BL Cipher” on a diagram stands for a baseline cipher. I’ve used it to find a difference between a PFS and non-PFS cipher’s handshakes, but as I’ve mentioned above there is no any evidence for Internet connections that PFS ciphers could degrade the performance.
Two conclusions that I could make out of this are:
- There is no any obstacle to move all servers to the categories #3 or #4.
- To move them to the the categories #1 or #2 a decision about not supporting legacy browsers should be made. That decision would make a perfect sense to me since it’ll improve the overall security of web applications.
