Certificate fraud: Protection against future "DigiNotars"
To better protect content providers against the distribution of bogus certificates, an HTTP header extension containing a fingerprint of their certificates has been proposed. This approach, which has been partly tested in Chrome, was presented by Ian Fette, Google Senior Product Manager, at a meeting of the Internet Engineering Task Force (IETF) in Taipei. Chrome users were able to detect the bogus DigiNotar certificates because Chrome had embedded the hashes of valid Google certificates. Back in July, the hacked DigiNotar certificate authority (CA), which has since gone out of business, was used to issue more than five hundred bogus certificates for companies including Google and various intelligence services.
Fette said that after that affair, other companies asked Google for a way to protect themselves against bogus certificates. As there are numerous CAs, the possibility that similar illegitimate certificates could be issued remains, explained the developer. However, Fette said that embedding the certification policy for all potential parties into browsers doesn't scale, and that he and his colleagues, Chris Evans and Chris Palmer, therefore advocate the dynamic pinning of public keys.
The HTTP header solution that they've described in a draft involves a hash of the SubjectPublicKeyInfo (SPKI) field of an X.509 certificate being sent to users as a header PIN. Fette said that potential hashes not only include those of the certificates that are valid for the current page, but also root certificate hashes of the CAs that are active for that page. During the stipulated validity period, requests would be checked to see if there is at least one correct pin and that a back-up pin is available. An error-free TLS connection is essential, and hashes will only be pinned once such a connection has been established.
Depending on how often providers plan to modify their certification policy, they can choose short or long pin validity periods. Experts say that very short validity periods of only a few hours don't make much sense, especially because the first pin check is crucial. However, Fette said that the concept is relatively easy to implement by the parties involved. The developer added that, apart from a browser update, end users would only notice the functionality once they receive a warning that a pin is incorrect or missing. Fette said that in practice pinning doesn't slow down responses. However, the risk that servers could become completely inaccessible after issuing incorrect pins can't be ruled out completely.
The focus of criticism from the IETF's WebSec working group, which now plans to monitor the draft's development, is the first request by the user. If this request is sent to a compromised server, pins won't work, and a legitimate page could, at worst, become inaccessible. Fette said that no real solution has so far been found for this "bootstrapping" problem. Furthermore, the IETF's discussion immediately revolved around potential attack scenarios that would allow governments to shut down pages that are pin protected. After all, pinning won't be effective if one's own certification agent has been hacked.
Members of the WebSec working group soon pointed out a parallel approach that is being investigated by the DANE working group and involves depositing certificates in a DNS that is protected via DNSSEC. Due to the closed trust chain, bootstrapping problems don't exist with this approach, and the available protection extends beyond HTTP requests. However, DNSSEC is not yet in widespread use.
(Monika Ermert / crve)