Transmissions

Tragedy of SSL

by Dragorn

Assuming we're all still around after December 21, 2012, we'll have to continue dealing with the slow (or not so slow, in some cases) collapse of the SSL trust system, and what we're going to do about it in the future.

There are two primary ways SSL is used, and both are subject to different, significant problems.  The first use of SSL is so obvious that most people never give it any thought: Go to a website with HTTPS, and your connection is encrypted.  Simple, right?  Even Facebook just switched to HTTPS by default (see, topical!).

When a browser calls up a HTTPS side, a large number of moving parts are engaged under the covers, with many ways for something to break without the user being aware, thanks to complex trust models.  While presumably most people reading 2600 know how SSL works, it bears repeating in brief.

Under HTTPS, the remote server provides a certificate which has been signed by a trusted authority, and which matches the DNS name of the server.  Optionally, it may also consult a CRL, or Certificate Revocation List, which allows a signing authority to "un-distribute" certificates previously released, if they're known to be compromised.

The list of trusted Certificate Authorities (CA) can vary by platform and browser type, but there are a lot, on the order of a hundred or more authorities.  Trusted authorities are trusted absolutely: Any certificate signed by them which matches the name record of the server is considered valid.  Any certificate authority can provide a valid certificate for any domain, which should raise warning flags already.

There are several ways to attack the certificate authority model.

The simplest is to just impersonate the entity you're attempting to get an illegitimate certificate for.  A CA is "trusted" in that there is an assumption that they have taken proper measures to confirm the identity of the requestor.  The exact procedures for determining this can vary from authority to authority.  Some may require information to be submitted via hardcopy, but some simply require that a file be made available on a website.  In other words: Sure, I own that site.  Because I owned it.

The second simplest attack against the trust model is to control the certificate authority.

Already there have been several highly publicized compromises of globally trusted authorities (such as DigiNotar), where the perpetrators issued certificates for high-profile domains like *.google.com.

While you would assume that a CA would be among the most hardened of targets available, it would appear that this isn't the case.  The final reports on the DigiNotar compromise (threatpost.com/en_us/blogs/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112) indicate that it had been compromised for at least a month before anyone detected it, had issued over 500 invalid certificates, and compromised the logs which would otherwise show what happened.

A more thorough compromise is hard to imagine (except, of course, one which goes completely undetected).  DigiNotar is hardly the only CA to be compromised, either - Symantec and Comodo both suffered breaches which resulted in false certificates being issued, and I'd comfortably bet that there are many more which have gone undetected or unreported.

Yet another attack against the certificate authority trust model is simple as well, so long as you have enough money or legal power.  Nothing prevents a CA from issuing a certificate for " * ", or "any domain, any server," except that being caught doing so could result in them being delisted from browsers and operating systems.  Every company must have a base of operations however, and a nation that the employees live in, placing them in danger of legal obligations.

Given the willingness of many nations to employ secret orders for wiretapping, data disclosure, and so on, it's entirely reasonable to expect that trusted certificate authorities may have been forced to issue or disclose certificates to law enforcement entities.

All of these vulnerabilities require two things: a compromised certificate, and the ability to redirect the user to it.  The latter can be accomplished easily on a small scale with Wi-Fi networks and is one of the reasons public open Wi-Fi can be such a problem, especially when coupled with naive users defeating security by accepting detected bogus certs.

On a grand scale (and a much more real threat), a hostile government can easily redirect traffic to sites used to organize protests, discuss things securely, or try to learn about topics the government has decided are forbidden.  On a non-governmental scale, attacks against the BGP routing system or DNS, which have both been demonstrated recently, could trap users from around the world on a false system.

The second way SSL certificates are used (and misused) is to present a self-signed certificate.  Self-signed certificates provide their own certificate authority - if this authority is present in the browser, then the certificate is trusted automatically (provided the name matches).  If the signing information is not present, the user is presented with the standard "invalid certificate, do you wish to accept?"

Browsers have been making it harder for users to skip this warning, but any chance a user is given to pick a security option, plan for them selecting the wrong option.  Since self-signed certificates have no "right" option, this is a major problem.  Thanks to the trust model, telling users to install the self-signed CA as a trusted authority can have extremely wide-sweeping impact; remember, any authority can provide a certificate for any site, so once someone trusts a hostile custom authority, it can issue certificates for any site on the Internet.  So long as the users' traffic can be intercepted, any site can be falsely represented.

Compound these problems with devices which either cannot or will not reasonably present certificate authority lists to the user.  (Mobile systems are often a big offender; Android, for example, had no way to delete a bad certificate, such as the DigiNotar one, prior to Android 4.  Anyone using older Android versions is by definition on older devices - devices least likely to see an update from the vendor to either Android 4 or to remove the DigiNotar entry.)

Some mobile devices also present the worse possible options - as far as security - as their defaults.  To pick on Android again (because I'm most familiar with it), the base options for email over IMAP are "Don't encrypt," "Use SSL" (which requires a commercial certificate), or "Use SSL and accept all certificates," which completely bypasses the certificate validation.  While the data may be encrypted in flight, there is no way of knowing who you are encrypting it to - making the whole thing rather useless.

Unlike many of the other topics which we have to deal with which seem to have no reasonable solution (such as secure public Wi-Fi), the mess with certificates has at least one fairly simple - and increasingly popular - solution: Certificate Pinning.

Under the pinning model, the hash signatures of all certificates in the chain are stored.  For future connections, all certificates in the path must match the previously recorded signatures.  The certificates can be cached in the code of a plug-in (for a browser) or in the application (for mobile devices), allowing the developer/site owner to ensure that no hostile entity (such as a state-owned or state-compromised certificate authority) is intercepting the traffic.  Instead of matching based on the chain of trust and the site name, the match is performed on pre-stored signatures.

Pinning can also be used dynamically, essentially shifting the trust model from "Do I trust this certificate?" to "Do I trust the network I am on?" when establishing the first connection.  While this doesn't necessarily offer protection from a pre-existing man in the middle style attack, it can give some additional level of assurance in some situations.  It's also far easier to tell users "establish the first connection from your LAN" than it is to tell them "compare this certificate fingerprint and..."

Pinning can't solve every problem, and in situations where multiple certificates might be in use for the same service (such as a server farm without a wildcard certificate), it may not be the best solution.  Uneducated (and uncaring) users can't be prevented from shooting themselves in the foot every time.  The ultimate solution has to be a combination of technology and education, but using pinning to prevent the user from making the wrong decision by never giving them the option to is a good first step.  Pinning is showing up in more mobile apps, which is almost definitely a good sign.