What is certificate pinning?
I'm superficially familiar with SSL and what certs do. Recently I saw some discussion on cert pinning but there wasn't a definition. A DDG search didn't turn up anything useful. What is certificate pinning?
There's a reasonably succinct description of certificate pinning in Wikipedia. For a more detailed description see the IETF Web Security (websec) Working Group's Public Key Pinning Extension for HTTP specification (currently an Internet Draft but probably soon to be become an RFC).
FYI: This question linked from http://www.theregister.co.uk/2015/03/24/google_ssl_cnnic/
I'm a co-author of the HTTP-Based Public Key Pinning RFC. The answers here are inaccurate in some ways (for example, PKP is separate from STS). Check out my blog post on the topic, https://noncombatant.org/2015/05/01/about-http-public-key-pinning/, or read the RFC itself, https://tools.ietf.org/html/rfc7469.
Typically certificates are validated by checking the signature hierarchy;
MyCertis signed by
IntermediateCertwhich is signed by
RootCert, and RootCert is listed in my computer's "certificates to trust" store.
Certificate Pinning was where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate, ignoring all the other root CAs that could otherwise be trust anchors. It was frequently also known as Key Pinning, since it was actually the public key hash that got saved.
But in practice, Key Pinning turned out to cause more problems than it solved. It was frequently misconfigured by site owners, plus in the event of a site compromise, attackers could maliciously pin a cert that the site owner didn't control. Key Pinning was deprecated in 2017, and was removed entirely from Chrome and Firefox in Nov. 2019. It was never supported to begin with by IE and Safari.
The recommended replacement is to use the Expect-CT header to tell browsers to require that the cert show up in Certificate Transparency logs.
Good answer, but it also depends on the browser; Google's Chrome browser pins the certificates for Google sites, so in your example, a Chrome browser would only trust specific google.com certificates known to be the correct ones (or the ones signed by the Google Internet Authority).
@KeithS the principle is browser-independent. Google pins certificates it knows using a slightly different mechanism (public key hashes instead of certificate hashes), but it's still close enough that calling it "pinning" is still correct.
@user93353 the certificate details are stored client-side and compared against those sent over the network.
Fuller details of how it's done (or how it might be done when draft proposals are standardised): https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://tools.ietf.org/html/draft-ietf-websec-key-pinning http://tack.io/index.html https://www.imperialviolet.org/2011/05/04/pinning.html
What I still don't understand about certificate pinning is - why am I still able to access Google apps through a corporate MITM? I know that I have the root cert for my corporation installed on my PC, but shouldn't Google throw an error when its sites are signed by a cert (my corporation's cert) that does not match one of the pinned certs? Maybe I'm misunderstanding how pinning works.
@JoshvonSchaumburg When the offending certificate is locally installed (not chained to a root store certificate) then Chrome doesn't do it's pinning checks. This is intentional. The idea is that if you are the owner of the local machine, then your decision should be final and Chrome shouldn't try to circumvent your actions. I think there's been some chatter in the past about giving some visual indication that the certificate is locally-trusted rather than globally-trusted, nothing has been implemented so far.
Your post confuses HSTS for HPKP. HSTS only ensures HTTPS is used; certificate pinning is HPKP's job.
@user2428118 No. The way you access hpkp configuration (at least when this was written) was as an option in your hsts setup.
@tylerl: ehhh... no? HPKP uses Public-Key-Pins header, while HSTS uses the Strict-Transport-Security header. They're totally unrelated.
@tylerl based on your comment are you saying if an iOS app implements certificate pinning then even that case its network requests would be revealed to something like Charles Proxy, because "if you are the owner of the local machine, then your decision should be final". If that's the case then wouldn't API keys be easily phished from network calls?