Many SSL Connections Missing Added Protection, Netcraft Says

How safe is SSL from being intercepted and decrypted? Not very, says Internet security and research firm Netcraft.

In a blog post entitled, "SSL: Intercepted today, decrypted tomorrow", Netcraft put forth a disturbing set of conclusions about the security of SSL in the real world. Spurred on by recent revelations about the National Security Agency logging and capturing encrypted traffic for possible decryption later, Netcraft pointed out how SSL (actually now referred to as "TLS") doesn't necessarily protect people in these circumstances:

"The reason that governments might consider going to great lengths to log and store high volumes of encrypted traffic is that if the SSL private key to the encrypted traffic later becomes available--perhaps through court order, social engineering, successful attack against the website, or through cryptanalysis--all of the affected site's historical traffic may then be decrypted at once. This really would open Pandora's Box, as on a busy site a single key would decrypt all of the past encrypted traffic for millions of people."

The post goes on to describe how SSL has, in theory, a protection measure against such compromises: perfect forward secrecy, or PFS, in which each SSL session is encrypted separately from every other. What's striking is how, according to Netcraft's analysis, the vast majority of SSL traffic doesn't use PFS.

Who's to blame for this?

No one particular authority, it seems; it's a by-product of the way websites, Web servers, Web browsers and end users all work together. While most Web browsers--Microsoft Internet Explorer being an exception--do support PFS, they don't always do so in conjunction with all websites, defaulting instead to less secure standards. Some websites don't even support PFS consistently: Google, for instance, supports it for some of its SSL sites, but not for others.

For perspective, I talked to Phil Pennock, a software engineer with Apcera, an early-stage software company based in San Francisco. He says Netcraft's concern over the way PFS is implemented was "fairly justified," and explained the problem further:

"TLS [the protocol that is synonymous with SSL] uses session keys for encrypting the traffic, [but] the public key crypto behind the certificates is only used to identify the end points and securely arrange those session keys. With only RSA in use [without PFS], the core secret material used to generate the session key is generated by the client and encrypted to the server's public key, so if you can recover the server's key later, you can decrypt that exchange, get the session key and then decrypt the traffic."

PFS, he explains, adds an additional layer of protection for each transaction. That said, the protection afforded by PFS is limited to data in flight, not data at rest, he says: "It does not protect against a warrant served upon the server operators, which forces them to retain all session keys and make them available." SSL also doesn't guard against the contents of the site itself being tampered with; it just protects the contents of communications in transit.

Pennock also notes that Netcraft's methodology for its investigation revolves around who decides which protocols to use for each session. Part of why the server is more often the deciding factor is because of the way higher security protocols impose more of a performance hit on both the client and server. Older, non-PFS protocols aren't as secure, but work faster.

"It's only because Google has been on the forefront of advancing TLS practice and specifications to speed up negotiation, and introduce technologies like SPDY, that it has able to now accept some performance sacrifice for security," Pennock says. He also noted that the next generation of processor chipsets--Ivy Bridge and beyond--may well make the performance issues of PFS-enabled SSL all but moot.

Should enterprises move to add PFS-enabled SSL to their servers? Yes, says Pennock, but not blindly.

One key element that must be in place when enabling PFS on the server side is entropy generation. A server must be able to produce high-quality pseudorandom numbers for the sake of good cryptography, a feature now supported in hardware on most late-model CPUs.

"Any public-facing gateway box should probably have a CPU with entropy generation," if it doesn't already have hardware entropy generation from somewhere else, Pennock says. "This affects enterprise email servers at least as much as Web servers." Servers should also have tools for internal SSL configuration reporting, and not rely on external reports to determine whether or not SSL is set up correctly.

Pennock says he finds it strange that Netcraft's blog post 'calls attention to the fact that "Russia, long-time target of U.S. spies, is the home of the developer of nginx, the Web server which uses PFS most often."

"Assuming that there must be a connection between nginx and the FSB," Pennock said, "is like assuming a connection between Apache and the NSA."

But Netcraft's basic observations' seem sound to him. Ultimately, SSL works best with PFS enabled, and site admins should do their best to make sure the majority of their users are kept as safe as possible.