Most security professionals have long understood at least some of the risks of the current ‘web’ or ‘chain’ of trust model for SSL security. To quickly recap for those of you who aren’t hip-deep in this day to day:

1. Your browser knows to trust a digital certificate because it’s signed by a root certificate, generated by a certificate authority, which was included in your browser or operating system. You are trusting that your browser manufacturer properly vetted the organizations which own the roots and sign downstream certificates, and that none of them will issue ‘bad’ certificates. This is not a safe assumption. A new Mac trusts about 175 root certificates, and Apple hasn’t audited any of them.
2. The root certificates are also used to sign certain intermediary certificates, which can then be used to sign other downstream certificates. It’s a chain of trust. You trust the roots, along with every certificate they tell you to trust – both directly and indirectly.
3. There is nothing to stop any trusted (root) certificate authority from issuing a certificate for any domain it chooses. It all comes down to their business practices. To detect a rogue certificate authority, someone who receives a bogus certificate must notice that the certificate they issued is different than the real certificate somehow.
4. If a certificate isn’t signed by a trusted root or intermediary, all browsers warn the user, but they also provide an option to accept the suspicious certificate anyway. That’s because many people issue their own certificates to save money – particularly for internal and private systems.

There is a great deal more to SSL security, but this is the core of the problem: we cannot personally evaluate every SSL cert we encounter, so we must trust a core set of root providers to identify (sign) legitimate certs. But the system isn’t centralized, so there are hundreds of root authorities and intermediaries, each with its own business practices and security policies. More than once, we have seen certs fraudulently issued for major brands such as Google and Microsoft, and now we see attackers targeting certificate authorities.

We’ve seen two roots hacked this year – Comodo and DigiNotar – and both times the hackers issued themselves fraudulent certs that your browser would accept as valid. There are mechanisms to revoke these things but none of them work well – which is why after major hacks the browser manufactures such as Microsoft, Mozilla, and Apple have to issue software updates. Research in this area has been extensive, with a variety of exploits demonstrated at recent Black Hat/Defcon conferences.

I highly recommend you read the EFF’s just-published summary of the DigiNotar issue.

It’s a mess. One that’s very hard to fix because:

1. Add-on models, such as Moxie Marlinspike’s Convergence add-on and the Perspectives project are a definite improvement, but only help those educated enough to use them (for the record, I think they are both awesome). The EFF’s SSL Observatory project helps identify the practices of the certificate authorities, but doesn’t attempt to identify breaches or misuse of certificates in real time. DNSSec with DANE could be a big help, but is still nascent and requires fundamental infrastructure changes.
2. Google’s DNS pinning in Chrome is excellent for those using that browser (I don’t – it leaks too much back to Google). I do think this could be a foundation for what I suggest below, but right now it only protects individual users accessing particular sites – for now, only Google. The Google Certificate Catalog is another great endeavor that’s still self-limiting – but again, I think it’s a big piece of what we need.
3. The CA market is big business. There is a very large amount of money involved in keeping the system running (I won’t say working) as it currently does.
4. The browser manufacturers (at least the 3 main ones and maybe Google) would all have to agree to any changes to the core model, which is very deeply embedded into how we use the Internet today. The costs of change would not fall only on evil businesses and browser developers, but would be shared among everyone who uses digital certs today – pretty much every website with users.
5. We don’t even have a way to measure how bad the problem is. DigiNotar knew they had been hacked and had issued bad certs for at least more than a month before telling anyone, and reports claim that these certs were used to sniff traffic in Iran. How many other evil certs are out there? We only notice them when they are presented to someone knowledgeable and paranoid enough to notice, who then reports it.

Dan Kaminsky’s post shows just a small slice of how complex this all is.

To summarize: We don’t yet have consensus on an alternate system, there are many strong motivations to keep the current system even despite its flaws, and we don’t know how bad the problem is – how many bogus certs have been created, by how many attackers, or how often they are used in real attacks. Imagine how much more confusing this would all be if the DigiNotar hacker had signed certificates in the names of many other certificate authorities.

Internally, long before the current hacks, our former intern proposed this as a research area. The consensus was “Yes, it’s a problem and we are &^(%) if a CA issues bad certs”. The problem was that neither he nor we had a solution to propose.

But I have an idea that could help us scope out the problem. I call it a ‘transitional’ proposal because it doesn’t solve the problem, but could help identify the issues and raise awareness. Call it an “Early Warning System for SSL” (I’d call it “IDS for SSL”, but you all would burn my house down). The canary in the SSL mine.

Conceptually we could build a browser feature or plugin that serves as a sensor. It would need a local list of known certificate signatures for major sites – perhaps derived from the Perspectives notaries or the Google Certificate Catalog. When it detected a mis-matched certificate it would report it up to the central registry, which could perform an analysis to detect bad certs. The registry would also tracks update origins in an attempt to detect traffic blocking. All this could be completely silent, or could be configured to alert, depending on user preference.

Some of the details:

1. We create a central registry of the signing chains for SSL certificates for major sites that are likely to be targeted in an attack. Even a few hundred would be a great start, and we might be able to get a lot more from existing projects. And we would allow anyone to opt in by registering their own chain.
2. When a browser is presented an SSL certificate (chain), it would check the offered chain against signatures from the registry.
3. Browsers would report each mismatch to the registry. The user could choose to see an alert before accessing the site, but this is purely optional – the system would work fine with most users silently accepting unknown certificates. This would avoid bothering users with ‘noise’ as websites deploy new certificates, while still offering a opportunity to disable verified malicious certificates.
4. The connection to the registry would be secured with a pre-shared key (PKI), but not using SSL.
5. The registry tracks two things – reported mismatches, and the anonymous location of each report.
6. If a suspicious certificate is reported, the registry can check with the nominal owner to determine whether it is merely a new legitimate certificate or actual fraud. This would take time and resources, although it could be automated somewhat.
7. The registry will thus identify potential problems and publicly report them.
8. The registry will also track request patterns, and can use these to help identify locations (ISPs or countries) which block connections to the registry.
9. For users who opt in, loss of connectivity to the registry or mismatched certificate can generate visible alerts. But the primary goal is to protect the entire system – not just individual users who opt into the system.

Unlike other projects, our goal is to create a public warning system, which even benefits users who do not use it directly – although direct users would benefit from direct alerting and better browser safety. We don’t need eveyone to use the tool – just enough people. It isn’t perfect, but can get us started on scoping out the problem. It could be a plugin, an add-on to something like NoScript that’s fairly widely used (or even Convergence), or better yet even built into browsers – like Chrome’s DNS pinning, with an additional callback function.

The downside is that this will take resources. And identifying blackout areas (e.g., hostile ISPs or nations blocking the registry) relies on generating enough initial traffic to identify baseline traffic patterns.

But we could tremendously increase our ability to detect usage of fraudulent certificates. Right now, anyone who can hack a CA has an excellent chance of intercepting a great deal of traffic and not getting caught – the detection mechanisms are simply too exotic and rare.

It looks like we have many of the bits and pieces we need – especially since at least one browser developer is already building in related features. It would be absolutely awesome if any of the big browsers built this in. Or perhaps an independent registry and warning service that’s open to any browser, with plugins to implement it.