Shostack + Friends Blog Archive

 

Smoke, Fire and SSL

Where there’s smoke, there’s fire, goes the adage.

And in the case of an allegedly-theoretical exploit outlined in a new paper by Chris Soghoian and Sid Stamm (the compelled certificate creation attack), the presence of a product whose only use it to exploit it probably indicates that there’s more going on than one would like there, too.  As Wired’s Threat Level notes:

Normally when a user visits a secure website, such as Bank of America, Gmail, PayPal or eBay, the browser examines the website’s certificate to verify its authenticity.

At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications — without breaking the encryption — by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.

The attack is a classic man-in-the-middle attack, where Alice thinks she is talking directly to Bob, but instead Mallory found a way to get in the middle and pass the messages back and forth without Alice or Bob knowing she was there.

The existence of a marketed product indicates the vulnerability is likely being exploited by more than just information-hungry governments, according to leading encryption expert Matt Blaze [link to http://www.crypto.com/blog no longer works as intended], a computer science professor at University of Pennsylvania.

As the paper explains,
While not known to most users, the CAs are one of the weakest links in the SSL public key infrastructure, a problem amplified by the fact that the major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government to issue a certificate for any particular website that all web browsers will trust without warning. Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments (both foreign and domestic) whom these individuals would never ordinarily trust.
The assumption that people are taught with SSL is that if the certificate is valid (meaning it is not expired and matches the hostname of the site they’re visiting) and trusted (meaning either they or a Certificate Authority vouch for its authenticity) then the connection is secure from eavesdropping.
The problem is that the decision of whom to trust is being made by people who may or may not share the same security interests as the browser user.  For example, if the United States’ own National Security Agency (NSA) were to compel a CA such as GoDaddy or Verisign or any of 264 CA’s to issue such a certificate within the guise of a National Security Letter, the CA would not only be compelled to comply, but would also be enjoined from ever talking about or acknowledging that they had been required to do so.
The NSA would insist (and might even believe) that they were doing it in the name of “keeping us safe,” but the people they’re targeting would probably feel differently.  Cybercriminals would likewise argue that they’re keeping their income streams safe.  Either way, outsourcing trust has come back to hurt the user.
Thus, the current system of Trustworthy Certificate Authorities has now scaled to the point of failure.  The entities whom we’ve engaged to determine who is or isn’t trustworthy have increasingly shown to have limited ability to deliver in that role.  The only way to be sure that a connection is trustworthy is to keep the trust relationship aligned with the people you actually know and do trust–i.e. run your own private CA and manage your own certificates.  That’s obviously beyond the capabilities of all but a very tiny fraction of the SSL-using world and of limited usefulness other than ensuring relatively secure transport between a closed set of sources.
In the long run, something else is needed.  I don’t know what, but hopefully Soghoian and Stamm’s paper will continue to help drive the discussion.
P.S. iang has also posted his own thoughts on this topic over at Financial Cryptography.
(Updated to clarify original links)

4 comments on "Smoke, Fire and SSL"

  • adam says:

    (Who’s that first quote?)

  • Pingback: Trusting SSL » Koz and Effect [link http://www.kozandeffect.com/?p=38 no longer works]
  • Brad Lhotsky says:

    I’ve always wondered who came up with the design of the SSL Infrastructure. I know it’s far from perfect, but why wasn’t the DNS Infrastructure either extended or simply copied? It wouldn’t solve the problem of NSA oversight, but it would make the terrain a bit less chaotic.

  • adam says:

    Entertainingly, I’d forgotten all about the fact that Ian Grigg and I wrote to ICANN on an issue closely related to this.

    See http://forum.icann.org/lists/net-rfp-verisign/msg00008.html and thanks to Ian (for driving the original letter) and Chris (for reminding me about it.)

Comments are closed.