8 ms·

Understanding Certificate Pinning

49 points by svenfaw 6y ago

Mediterraneo10 6y ago
Years ago I read a blog that taught the series of steps needed to perform GNUTLS certificate pinning for Emacs use. At the time, it seemed like a convenient way to boost security. After all, services were only renewing their certificates every 2–3 years, so once you set up your configuration, you wouldn't have to change it for a long time. But then Lets Encrypt came along and was widely adopted. LE thinks that it is best that certificates expire after only a few weeks. So, if you have pinned a lot of certificates, you start to feel that it is too much work to manage that configuration, you constantly have to update it.
- elithrar 6y ago
  You shouldn’t be pinning to your leaf certs, which is the only reason LE certs would be a problem here.
  - kingosticks 6y ago
    Possibly stupid question here (this is not my domain), but what is the alternative to pinning the client to use your leaf certs? If it's pinning to your root cert, then isn't that much more of a pain if/when you need to revoke what the client is using? Or is the correct alternative to pin "to one or multiple rsa public keys" as mentioned in the sibling comment?
    - elithrar 6y ago
      Late reply, but: if you really must pin (and you probably shouldn’t), pin to public keys, not the certs in the chain.
      - kingosticks 6y ago
        Thank you!
- jtdressel 6y ago
  Instead of pinning the cert, you can pin to one or multiple rsa public keys. Then you can use those keys when you generate signing requests (CSR) from lets encrypt.
dcow 6y ago
Cert pinning is an anti-pattern. No need for the CA infrastructure if you're going to bypass the CA infrastructure. If you control the software on both sides, which is required for cert pinning, then you can use self-issued certs. Also: roll your certs frequently. Shameless plug for https://smallstep.com/cli https://smallstep.com/cli which makes the process of issuing and rolling certs (incl. client certs for mutual TLS) easy enough to be workable in a modern application.
- castillar76 6y ago
  I totally agree: pinning to a single CA is super-fragile and a terrible idea, and if you don't have a need for public certs, doing a proper private PKI (Small-step is a good choice here!) is a good place to go as long as you can run it properly. However, whether you're running your own or pulling public certs, you should go into any PKI setup assuming you'll need to change out all the certs at some point. If you're going private, make sure you have a mechanism to replace everything--yes, including that private root you just created!--in a safe and secure fashion. Preferably, that would include some manner of doing so that doesn't involve blowing everything up and leaving existing clients high and dry...but that's a business decision to make. If you're going with public certs, you still have to make that assumption. I see too many developers still pinning trust to a single root CA like Let's Encrypt or GoDaddy and then being stuck when the CA in question is revoked, replaced, expires, or is booted out of public trust, or just because their business insists they use something different. The solution to this is a trust store, which you can make as minimal as you want to: pick two or three public root CAs, stick them in a blob, and tell your app to accept nothing else. That leaves you an out, for the next time the cert industry has a Symantec-like event and everyone has to get off that train right away, since you can move from one of those to another one without having to change anything in the app.
- kayson 6y ago
  How does using a self-issued cert address the concern of mitm proxying? (specifically, a user intercepting their own traffic to reverse engineer the api/protocol)
  - 6y ago
atarian 6y ago
>It must be emphasised that if any single CA is breached, then all of TLS breaks. It doesn’t matter what CA you used for your website, it only matters what CA your attacker uses. How is that possible? If a CA is breached, doesn't that just mean it can create certs impersonating other sites? How does that break all of TLS?
- resist_futility 6y ago
  Do you keep track of what CA each website you visit is currently using?
- bluecmd 6y ago
  No, you also need to be able to MITM. Snooping the traffic is not enough to do harm.
- tialaramex 6y ago
  Yes, it's not really helpful for the site to say this breaks "all of TLS" which doesn't itself have any opinion about why you'd trust this or that certificate. TLS per se is unaffected. But if a CA which is trusted in the Web PKI is "breached" then the nature of that breach determines the consequences for anybody who trusts the Web PKI (which means popular web browsers and a good deal of other software) * If the breach results in bad guys having the root private key (typically realised as a physical device in a safe) then they can issue any certificate or certificate hierarchy using that key and it would (until you update things not to trust it) work. But this is extremely unlikely, it has probably never happened (it's unclear for Diginotar but appears the root was not actually taken by bad guys, they broke into a bunch of servers they didn't conduct a physical robbery) * If the bad guys get one or more Intermediate private keys - which are online because they're used in the actual process of minting you a certificate although they're supposed to be protected inside hardware that shouldn't give anybody the keys - they can make any certificates under that intermediate, including further sub-CAs. Unlike a root the intermediate can "just" be revoked, and mechanisms to make that stick in practice exist for all major browsers. * If the bad guys just break into servers that are responsible for issuance it's trickier. They might be able to cause the Intermediates to sign some certificates but not others depending on what they broke into exactly. For example they may be unable to falsify the date as there's no reason the server they broke into would be allowed to choose the date on a certificate, or they might be obliged to obey rules like CAA checking even if they don't want to because it's done by some other system they can't override. If the owners realise what's happening and turn off the power, the access goes away, the bad guys don't have the keys so they can't make more certificates. * If the bad guys just broke into some subsidiary system they may only be able to cause issuance / re-issuance of certain specific certificates that system was allowed to cause. e.g. suppose Big Corp contracts with some CA to issue many certificates like springfield.bigcorp.example and smallville.bigcorp.example - there may be authority on file to issue any such certificate until say 2020-08-04, and if bad guys guess that Big Corp's password is "letmein123" they can use that existing authority to make themselves a certificate for fart.bigcorp.example no problem - but that doesn't get them a certificate for news.ycombinator.com or google.com without some other attack.

49 points by svenfaw 6y ago

Years ago I read a blog that taught the series of steps needed to perform GNUTLS certificate pinning for Emacs use. At the time, it seemed like a convenient way to boost security. After all, services were only renewing their certificates every 2–3 years, so once you set up your configuration, you wouldn't have to change it for a long time. But then Lets Encrypt came along and was widely adopted. LE thinks that it is best that certificates expire after only a few weeks. So, if you have pinned a lot of certificates, you start to feel that it is too much work to manage that configuration, you constantly have to update it.

elithrar 6y ago
You shouldn’t be pinning to your leaf certs, which is the only reason LE certs would be a problem here.
- kingosticks 6y ago
  Possibly stupid question here (this is not my domain), but what is the alternative to pinning the client to use your leaf certs? If it's pinning to your root cert, then isn't that much more of a pain if/when you need to revoke what the client is using? Or is the correct alternative to pin "to one or multiple rsa public keys" as mentioned in the sibling comment?
  - elithrar 6y ago
    Late reply, but: if you really must pin (and you probably shouldn’t), pin to public keys, not the certs in the chain.
    - kingosticks 6y ago
      Thank you!
jtdressel 6y ago
Instead of pinning the cert, you can pin to one or multiple rsa public keys. Then you can use those keys when you generate signing requests (CSR) from lets encrypt.

dcow 6y ago

Cert pinning is an anti-pattern. No need for the CA infrastructure if you're going to bypass the CA infrastructure. If you control the software on both sides, which is required for cert pinning, then you can use self-issued certs. Also: roll your certs frequently. Shameless plug for https://smallstep.com/cli https://smallstep.com/cli which makes the process of issuing and rolling certs (incl. client certs for mutual TLS) easy enough to be workable in a modern application.

castillar76 6y ago
I totally agree: pinning to a single CA is super-fragile and a terrible idea, and if you don't have a need for public certs, doing a proper private PKI (Small-step is a good choice here!) is a good place to go as long as you can run it properly. However, whether you're running your own or pulling public certs, you should go into any PKI setup assuming you'll need to change out all the certs at some point. If you're going private, make sure you have a mechanism to replace everything--yes, including that private root you just created!--in a safe and secure fashion. Preferably, that would include some manner of doing so that doesn't involve blowing everything up and leaving existing clients high and dry...but that's a business decision to make. If you're going with public certs, you still have to make that assumption. I see too many developers still pinning trust to a single root CA like Let's Encrypt or GoDaddy and then being stuck when the CA in question is revoked, replaced, expires, or is booted out of public trust, or just because their business insists they use something different. The solution to this is a trust store, which you can make as minimal as you want to: pick two or three public root CAs, stick them in a blob, and tell your app to accept nothing else. That leaves you an out, for the next time the cert industry has a Symantec-like event and everyone has to get off that train right away, since you can move from one of those to another one without having to change anything in the app.
kayson 6y ago
How does using a self-issued cert address the concern of mitm proxying? (specifically, a user intercepting their own traffic to reverse engineer the api/protocol)
- 6y ago

atarian 6y ago

>It must be emphasised that if any single CA is breached, then all of TLS breaks. It doesn’t matter what CA you used for your website, it only matters what CA your attacker uses. How is that possible? If a CA is breached, doesn't that just mean it can create certs impersonating other sites? How does that break all of TLS?

resist_futility 6y ago
Do you keep track of what CA each website you visit is currently using?
bluecmd 6y ago
No, you also need to be able to MITM. Snooping the traffic is not enough to do harm.
tialaramex 6y ago
Yes, it's not really helpful for the site to say this breaks "all of TLS" which doesn't itself have any opinion about why you'd trust this or that certificate. TLS per se is unaffected. But if a CA which is trusted in the Web PKI is "breached" then the nature of that breach determines the consequences for anybody who trusts the Web PKI (which means popular web browsers and a good deal of other software) * If the breach results in bad guys having the root private key (typically realised as a physical device in a safe) then they can issue any certificate or certificate hierarchy using that key and it would (until you update things not to trust it) work. But this is extremely unlikely, it has probably never happened (it's unclear for Diginotar but appears the root was not actually taken by bad guys, they broke into a bunch of servers they didn't conduct a physical robbery) * If the bad guys get one or more Intermediate private keys - which are online because they're used in the actual process of minting you a certificate although they're supposed to be protected inside hardware that shouldn't give anybody the keys - they can make any certificates under that intermediate, including further sub-CAs. Unlike a root the intermediate can "just" be revoked, and mechanisms to make that stick in practice exist for all major browsers. * If the bad guys just break into servers that are responsible for issuance it's trickier. They might be able to cause the Intermediates to sign some certificates but not others depending on what they broke into exactly. For example they may be unable to falsify the date as there's no reason the server they broke into would be allowed to choose the date on a certificate, or they might be obliged to obey rules like CAA checking even if they don't want to because it's done by some other system they can't override. If the owners realise what's happening and turn off the power, the access goes away, the bad guys don't have the keys so they can't make more certificates. * If the bad guys just broke into some subsidiary system they may only be able to cause issuance / re-issuance of certain specific certificates that system was allowed to cause. e.g. suppose Big Corp contracts with some CA to issue many certificates like springfield.bigcorp.example and smallville.bigcorp.example - there may be authority on file to issue any such certificate until say 2020-08-04, and if bad guys guess that Big Corp's password is "letmein123" they can use that existing authority to make themselves a certificate for fart.bigcorp.example no problem - but that doesn't get them a certificate for news.ycombinator.com or google.com without some other attack.