367

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?

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
Son of the Wai-Pan
  • 3,795
  • 3
  • 11
  • 5
  • 3
    There's a reasonably succinct description of [certificate pinning](https://en.wikipedia.org/wiki/Certificate_pinning#Certificate_pinning) in Wikipedia. For a more detailed description see the IETF Web Security (websec) Working Group's [Public Key Pinning Extension for HTTP](http://tools.ietf.org/html/draft-ietf-websec-key-pinning) specification (currently an Internet Draft but probably soon to be become an RFC). – user30473 Feb 18 '14 at 10:50
  • 1
    FYI: This question linked from http://www.theregister.co.uk/2015/03/24/google_ssl_cnnic/ – Richard Mar 25 '15 at 09:23
  • 12
    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. –  Mar 26 '16 at 04:28

6 Answers6

266

Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which 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.

tylerl
  • 82,665
  • 26
  • 149
  • 230
  • 9
    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 Feb 05 '13 at 19:58
  • 3
    @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. – tylerl Feb 05 '13 at 21:52
  • 3
    So how is it done? Certificate Pinning, I mean – user93353 Apr 28 '13 at 12:19
  • 3
    @user93353 the certificate details are stored client-side and compared against those sent over the network. – tylerl Apr 29 '13 at 22:49
  • 1
    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 – armb Sep 04 '13 at 09:22
  • "**Hongkong Post Office**" should make you think – basic6 Jun 04 '14 at 20:31
  • 2
    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. – jay-charles May 03 '15 at 21:55
  • 6
    @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. – tylerl May 03 '15 at 22:24
  • 5
    Your post confuses HSTS for HPKP. HSTS only ensures HTTPS is used; certificate pinning is [HPKP](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)'s job. – user2428118 Apr 25 '17 at 08:08
  • @user2428118 No. The way you access hpkp configuration (at least when this was written) was as an option in your hsts setup. – tylerl Apr 25 '17 at 14:46
  • @tylerl: ehhh... no? HPKP uses Public-Key-Pins header, while HSTS uses the Strict-Transport-Security header. They're totally unrelated. – Lie Ryan Mar 07 '19 at 09:50
  • @tylerl based on [your comment](https://security.stackexchange.com/questions/29988/what-is-certificate-pinning/84425#comment146160_29990) 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? – Honey Aug 01 '19 at 20:22
  • My post referenced the HSTS header rather than HPKP because at the time, the HPKP header hadn't yet been defined, and Chrome overloaded the HSTS header to pin keys. That's not what they do today; in fact, today nobody uses key pinning at all since the feature has been removed. – tylerl Dec 01 '19 at 09:07
38

It's ambiguous, but it refers to solutions for an issue in SSL certificate chain verification. Essentially, trust in SSL boils down to root certificates, the certificates your system trusts in to be genuine. Those either come with your OS or with your browser. If one of those is compromised, all certificates signed by this and transitively signed certificates are to be treated as compromised.

  • TACK or Public Key Pinning Extension (referred to as cert pinning by chrome, apparently) allows the admin of a server to "pin" a certificate authority's (CA) public key signature to a certificate, which is verified by the client (delivered via SSL extension). If the CA certificate's key is different upon retrieval of the certificate chain, the CA certificate is likely to be compromised. Source

  • Cert pinning can also refer to importing a host's certificate in your trust store, rather than trusting CA certificates. This mitigates the risk of a CA cert being compromised but forces you to update certificates if they expire manually. Source

Whymarrh
  • 312
  • 3
  • 17
fuero
  • 531
  • 4
  • 7
27

SSL server certificates come from the X.509 world. The client verifies the validity of the server's certificate by validating a lot of cryptographic signatures from Certification Authorities. The beauty of the scheme is that it is stateless: a given server could change its certificate every five minutes, and it would still work with clients.

It has been argued that while supporting fast-revolving certificates is awesome but useless, because in practice a given server changes its certificate once per year; indeed, an early certificate switch is indicative of some ongoing fishy business. Certificate pinning is a way for a server to state that this should not happen under normal conditions, and that the client should raise a metaphorical eyebrow should an unexpected certificate switch occur. This is a protocol extension, suggested but not widely supported yet. Actually there seems to be several relatively similar, competing proposals.

See also Convergence, yet another protocol extension which can be thought of as "certificate pinning by trusted third parties". Convergence and the certificate pinning proposals all dance around the same core idea, which is to have some state in the client (or somewhere, at least), and trigger security warnings when certificates change too often or too early. Whether any of these proposals will ever reach wide acceptance (i.e. will be implemented in a compatible way by IE, Firefox, Chrome and Safari, and will be used by most SSL server sysadmins) is anyone's guess.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 1
    I'd claim that Convergence (or Perspectives) are not protocol extensions but a side channel for verifying that the host is using the same certificate when viewed from different locations around the globe and that this situation has around for a while. The core difference to other measures is that the host cannot affect this verification, unlike other cert pinning methods. – Mikko Rantalainen Aug 29 '13 at 05:55
  • I know this is not the selected answer but for me this was the explanation I could understand. Thanks Tom. – Sizons Jul 03 '17 at 08:40
  • Seconding Sizons, expressive and concise explanation by Tom. Here’s [MDN docs for the implementation of pinning that appears to be the standard today (HPKP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning). – Anton Strogonoff Aug 07 '18 at 12:07
  • "Certificate pinning is a way for a server to state..." Certificate pinning is something that happens on the client side and server does not influence it. More precisely we could say that "Certificate pinning is a way for the developer of the distributed system to state...". – astraujums May 07 '21 at 13:53
24

Generally what happens in a HTTPS connections is that client asks for SSL certificate from the SSL compliant server it is communicating with over https. Server will provide a certificate from its key store. After client receives this certificate it validates its credentials depending on whether

  • hostname is same as requested
  • has a verifiable chain of trust back to a trusted (root) certificate [from clients trust store]

Now if connections are proxied and you can get the device to trust your (rogue) root CA certificate then you can intercept the secure connections. This is essentially man-in-the-middle attack. Now here is what happens in SSL pinning which potentially adds an extra security layer from man-in-the-middle attacks-

App will bundle the known server certificates with itself. When app tries to make a secure connection with the server, it validates the certificate received by the server with the ones it has bundled with. So even if OS validates the received certificate chain against a (potentially rogue) root CA, the app will reject the connection displaying network error.

Note: I have tried to answer this question from a perspective of SSL pinning in Android Apps. SSL pinning is easily possible in such Apps because the app already knows the server (hostname) it is going to connect to. Same may be difficult to implement in browsers though. I think chrome browser already implements this.

I have also wrote a sample code demonstrating cert pinning in Android. You can find it on github. You can also find the same app on playstore.

More information :

Honey
  • 103
  • 7
Aniket Thakur
  • 1,015
  • 1
  • 10
  • 11
  • FWIW there's an issue with certificate pinning: 1. It makes debugging difficult. Because you can't connect it to Charles — unless you disable it during debugging 2. Your certs will eventually expire. – Honey Aug 28 '19 at 21:31
15

Certificate pinning allows to bypass standard certificate authority chains to mitigate the risk of an valid certificate be issued to a criminal.

Motivation for a new solution...

SSL/TLS certificates are signed by other certificates. Browsers normally recognize a certificate as valid when in some point of this signature chain a trusted entity is found. The signatures of the trusted entities comes in the basic installation of the operating system and browsers. It is an embedded list of about 100 entities.

If one of the trusted certificate authority are compromised or if the certificate authority is victim of a fraud they can issue an valid certificate to a criminal. The criminal will have a perfect SSL/TLS certificate in your name. The criminal will be able to make successful and believable "man in the middle" attacks. The user will see a valid certificate info to your website.

Also, is not difficult to convince the user to install a new trusted certificate authority. For instance, in Brazil, the official certificate authority is not recognized by the main browsers and everyone has to install an additional certificate authority. Browsers got very good at this: only click in a link and answer yes. To reach this level of usability I believe this is a common task worldwide.

The certificate authorities can not be fully trusted. The process to get a certificate is by no means secure. I already bought one in a company and did not much more than pay for it. Of course is way better than nothing. But needs improvement.

What is pinning?

On the first access to the website secure.example.com, the website send a hidden message to the client browser that loosely translates as:

"in the next N days the secure.example.com website will use the certificate CECECECE. In that period do not accept another certificate, even if the certificate authority claims it is valid for this website. If it happens notify me at http://100.200.100.200/callbacks/warn_pinning.php".

Pinning solves the problem?

It does not solve the weakness of the certificate authorities certificate signing process. But minimize the window of opportunity of a criminal to get by with a man in the middle attack. The attack will only work if gets the user in his or hers first access to the website.

It is similar to the SSH security. On first access the signature of the key of the server is saved. If in future access the identification does not match the system generates an warning. The warning is taken seriously because only happens when you make real changes.

The best thing for a big company is to get notified through clients complaints that someone has issued a real TLS/SSL certificate in their name to a criminal. As I understand the pinning mechanism was proposed by Google

Application Level Pinning

Pinning can also be made outside the browser, by compile the real certificate fingerprint in a app.

Lucas
  • 439
  • 3
  • 5
  • 1
    I suppose in the case of DNS poisoning and similar where the IP for the domain name is changed by an attacker, certificate pinning would also help (assuming you visited the site earlier). – Steen Schütt Oct 16 '16 at 06:26
  • Good question. On encrypted connections it will. But I do not know if pinning a site will prevent unencrypted connections to work. If does not, the attacker will still be able to make a believable attack using unencrypted connections. If does not is only question of time. Make no sense at all to allow unencrypted connections for a pinned site. – Lucas Oct 17 '16 at 11:42
  • I'd thought cert-pinning is an additional mechanism rather than a replacement of a normal validation. If this validation is by-passed completely (assuming the certificate is not self-signed), then how the certificate (signature) is validated/checked in the first place? – zgulser May 17 '21 at 10:55
-4

I think it is just a HSTS implementation to retain SSL certificates of browser clients when a MITM sslstrip attack is made against the web user

Joseph
  • 1
  • 8
    Certificate pinning is different. At present HSTS doesn't provide any way to pin to a single certificate; instead, HSTS is a boolean that lets a site say "SSL only please" (but doesn't let the site restrict to a single certificate). Certificate pinning is an extension/different mechanism. – D.W. Jun 27 '13 at 22:03