Sophos Cloud Optix
You may have heard of certificate pinning.
Very simply put, it’s a funky name for a sort of “allowlist” of digital certificates. It is intended to supplement (or even to supplant) the chain of trust on which normal digital certificates, such as those used for HTTPS, rely.
We’ve explained the chain of trust before in varying levels of detail, but the concept is straightforward for securing traffic such as web browsing:
1. You send out a site certificate that is a public key people can use to encrypt traffic to your site, combined with a digital signature that identifies it as yours.
But the name in a certificate is just a text string typed in when it was created, so anyone can make a certificate that says it’s yours. How do people know it is yours? Here’s how:
2. The site certificate is digitally signed with an intermediate certificate owned by a CA (certification authority) that vouches for you.
The intermediate certificate may itself be signed with another intermediate certifcate, and so on, until finally:
3. The last intermediate certificate in the chain is digitally signed by a root certificate that belongs to a CA that vouches for the CA (that vouches for the CA, etc.) that vouches for you.
And your browser, or your operating system, or whatever, contains a list of root certificates it trusts implicitly.
The browser I’m using now trusts hundreds of roots, from the resoundingly named “A-Trust Gesellschaft fuer Sicherheitssysteme im elelektronischen Datenverkehr GmbH” out of Vienna, to the spaceage-sounding “XRamp Security Services Inc”, now a subsidiary of Trustwave.
So there’s quite a lot that can go wrong. You can forge a certificate in my name by suborning, hacking, tricking or cajoling any CA that owns a trusted root certificate, and begging, borrowing or battering them into signing your bogus item. Most browsers will accept it, just like that.
In real life, we rely on extra checks and balances to prevent this sort of fraud.
Imagine, for example, that you’re a tall, thin female with a Minnesota driving licence and distinctive left-handed cursive writing with a loopy flourish.
You’d probably expect your bank to be suspicious if a short, chubby bloke turned up at a branch and tried to draw from your account using block capitals and a Canadian passport, even if his name was the same as yours.
Certificate pinning tries to provide the same sort of “this just isn’t the Mrs Jeanette Smith we’re used to” warning, by keeping an independent record – an allowlist, or whitelist – of what your certificate is supposed to look like.
Of course, this isn’t without its own problems. If you want or need to change your certificates, you can’t just let the new certificates speak for themselves: you have to update the pinning data, or allowlist.
Nevertheless, there is something unappealing about a crook being able to sign himself certificates for any web property he likes just because he’s broken into a root CA’s network.
(It’s happened, and on a huge scale. Security company Vasco’s Dutch subsidiary Diginotar “signed” more than 500 bogus digital certificates in the name of major brands such Facebook, Twitter, Microsoft and Google. It didn’t help that Diginotar apparently waited several weeks before coming clean about the breach.)
Anyway, Microsoft is experimenting with a similar idea for “pinned signatures” on signed software. This means that if I break into your root CA servers, I can’t just start minting my own signed versions of things like operating system drivers and core software that your computer will blindly trust.
Pinning has helped with web security. Will it work for program files?
Have a listen as Patrick Gray, host of the renowned Risky Business security podcast, and I discuss this very question:
Then let us know in the comments what you think about certificate pinning.
Do we really need yet more PKI (public key infrastructure) to bolster the PKI that we already have for the public keys signed by everyone from A-Trust to XRamp?
It won't do any good. If users get used to clicking OK when real certificates get updated, they'll also click OK when someone hijacks the site and writes, oh, we updated our certificates.
Certificates are introduced for the model of "Trusted Third Party". Since the model is broken (by fake certificates), it does not introduce additional security at all.
And anyway, certificates need to be refreshed, so the whitelist needs to be updated – and since the trusted third party model is broken, there's no way to trust any whitelist update.
Yes – indeed – the model is itself broken….but that was clearly understood in the original 1978 paper from MIT. For example, which smart cell-phones/tablets really look up the revocation lists in real time? Any?
No – Diffie & Hellman clearly understood in the 1970s that the only real solution was a trusted "public key registry (PKR)" as a true public key infrastructure. No need for certificate revocation ( which does not scale anyway – as was pointed out 35 years ago) and, in principle, no need for certificates at all. Back in those days- remember-we didn't have the Internet and – yes – concurrent comms sessions were not available.
What I mean is – simple – we couldn't easily establish connection and then get the relevant public key – without DROPPING the first line and then re-establishing it. Easy nowadays.
Think of a PKR based PKI rather like a trusted telephone exchange – you dial and trust that the exchange links you to the dialled number!
New ideas based around DNSSEC/DANE may be the way to go in the IPv6 future. We need a lot more R&D and experiments – yes, at large scale on real test systems.
bullshit at the end of the day is still bullshit