The DigiNotar, Comodo, and other recent CA incidents has made it clear that the current CA/SSL model requires at least some reinforcement. An enhanced form of HSTS has been under discussion for a while, and this week an initial submission was made to the IETF’s websec group. It would work by allowing an HSTS response to ‘pin’ an HSTS enabled domain to a list of root certificates, end entity certificates, or public keys used from end entity certificates. This allows, for example gmail.com to say that for the next 6 months, only certificates from a set of CAs should be trusted by a browser. While it’s not a panacea, it would help detect and prevent SSL MITMing like that detected in the DigiNotar case. There is a bootstrap problem (the first time someone visits a site, the browser can be fooled), but incremental improvement and defence in depth is the order of business here. If you’re not careful, pinning could have negative consequences, and the spec is careful to minimise these – notably that if you limit yourself to a single CA, you can effectively be extorted when your existing certificate expires, as you have no choice but to pay for a new certificate from the pinned CA.
It’s this flexibility which introduces what I think is a difficult to solve problem. If you’re running a non-SSL site, and an attacker can gain access to your DNS (as recently happened to theregister.co.uk and others), they can ‘pin’ your users to a public key which you don’t have the private key to, and which isn’t revocable. At that point, you either rely on the browser vendors to somehow decide that you really do own your site, and push some kind of special unpin message to all browsers, or you pay up to the attacker to buy the private key, from which you can have a cert issued, and which you can then use to serve your site, and probably downgrade from pinning and HSTS.
In this case, we’ve essentially shifted trust from CAs to DNS registrars, who inevitably have less security expertise. Without HSTS+pinning, theregister.co.uk just had to wait for the registrar to correct the whois records, and for the DNS to propagate. With pinning, a similar registrar failure could have a much longer lasting impact. There are variants to this attack which simply require acting as a MITM, but in those cases, gaining a CA cert for a target domin is considered much harder.
This attack essentially targets the bootstrap phase which we already knew wasn’t secure. After a few days pondering solutions to the problem, the solutions I can come up with essentially further weaken the bootstrap phase, but enable pinning over the long-term without these problems for non-secured sites.
My proposal is to soften the effect of the ‘pin’ for 72 hours from when a domain is first pinned. If, in that period, a certificate which doesn’t correspond to the pin is encountered, the browser must apply heuristics to determine what to do. This may include user input or communication with white/blacklist services. It must not blindly obey the pin.
Why is it important to put this into the spec? If I think about the costs of setting up a truly secure and trustworthy blacklist/unpin service, the task is as complex as running a CA. I think it’s unreasonable to expect that browser vendors will want to get into that business. And even if they did, the time it might take for them to correctly identify the domain owner and correct pinning status would likely be lengthy. Any site owner setting a pin would be rightly upset if their site was incorrectly unpinned. Providing a short window (at the already weak boostrap phase) where a lower set of expectations is codified would provide cover to implement sensible heuristics and low-bureaucracy services to mitigate the worst of the problem, without implying that those same services would be appropriate for a general pin revocation scenario.
