3 ms·

> Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer I don't think you'd typica

> Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer I don't think you'd typically pin intermediates if that was your goal: you'd pin the site cert you control. It could be as simple as a whitelist of certificate SHAs.

tialaramex 3y ago
I'd recommend pinning (your) keys because knowing cert SHAs ahead of time means you need the certificates themselves and in a nasty situation the CAs you relied on to issue those certs may be out of the picture, if you're pinning a key that's fine, CA #5 will cheerfully issue you a brand new certificate against the same key you were using with CA #1 before something went badly wrong - but with cert SHAs you have to bootstrap all of that fresh if it happens. If you pin keys you can even pin a key you haven't and never plan to use, keeping the corresponding private key in the company safe as a hedge against something going badly wrong.
- jcalvinowens 3y ago
  I completely disagree with you: reusing private keys is an enormous vulnerability. It's really important to rotate them. It's very easy to avoid the pitfall you mentioned by having multiple valid certs with different expiry dates. You can easily use multiple CAs. Done your way, a single leaked private key means your entire site is compromised indefinitely. That's unacceptable to me.
  - tomputer 3y ago
    > reusing private keys is an enormous vulnerability. As long as the private key is stored/handled safely and RSA/ECC is not broken, it is not vulnerable. I do agree that key rotation is better/recommended practice. > a single leaked private key means your entire site is compromised The leak is the actual vulnerability. As long as the leak is still there and you are not aware of the compromised private key, a fresh new private key will probably leak again. However, the chances of leaking may be greater if a private key has to be used in multiple locations.
toast0 3y ago
Pinning the site cert (or its key) is not great because it makes it very hard to rotate your certificate or key. And you've got to be able to do that, in case your key is disclosed or possibly disclosed. Pinning intermediates doesn't make a lot of sense; unless you have a deep relationship with the CA, they can and do change intermediates, and may not be able to issue from the old intermediate after the change. But, I've been involved in cert pinning where we had to pin intermediates, because that's the only viable information the client API returned we could use for pinning (and really, it was pinning based on the name of the intermediate --- any system trusted Root CA could have made an intermediate specifically to bypass our pinning, but it was the best we could do on that platform; of course, this was also the platform where we ended up with a wrong pin in our final build (platform owner shut down their app signing CA), which meant some ugly workarounds). Pinning roots makes sense, but you need to pin more than one. And roots from more than one organization. And you need a succession plan. You can't use a new root on an existing hostname until all of the deployed clients with pins that could use that hostname have become irrelevant. If your all your trusted CAs stop issuing, you're pretty screwed. You can sometimes use an in-house root, which makes continuity easier, but not if you need to share hostnames with browsers. You can't get an entity cert signed by two issuers, so there's no way to present a cert that is trusted by browsers and also signed by your root. You can present alternate paths for the issuers of your cert (and any intermediates) and if the x.509 libraries do the right thing, any valid path is accepted; but not all libraries do the right thing, and again, that doesn't apply to the entity cert.
- jcalvinowens 3y ago
  Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.
  - toast0 3y ago
    Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to the system root store and intercepts traffic with the intent of passing it through but does not do so correctly and causes hard to diagnose errors. A pinned cert makes it easy to detect these MITMs and refuse to work if they're in place. A dedicated reverse engineer is "just" going to patch out the pin, and go on with their day, no big deal. But ISP MITM or corporate MITM or on device MITM is going to be stopped, and that's worthwhile.

tialaramex 3y ago

I'd recommend pinning (your) keys because knowing cert SHAs ahead of time means you need the certificates themselves and in a nasty situation the CAs you relied on to issue those certs may be out of the picture, if you're pinning a key that's fine, CA #5 will cheerfully issue you a brand new certificate against the same key you were using with CA #1 before something went badly wrong - but with cert SHAs you have to bootstrap all of that fresh if it happens. If you pin keys you can even pin a key you haven't and never plan to use, keeping the corresponding private key in the company safe as a hedge against something going badly wrong.

jcalvinowens 3y ago
I completely disagree with you: reusing private keys is an enormous vulnerability. It's really important to rotate them. It's very easy to avoid the pitfall you mentioned by having multiple valid certs with different expiry dates. You can easily use multiple CAs. Done your way, a single leaked private key means your entire site is compromised indefinitely. That's unacceptable to me.
- tomputer 3y ago
  > reusing private keys is an enormous vulnerability. As long as the private key is stored/handled safely and RSA/ECC is not broken, it is not vulnerable. I do agree that key rotation is better/recommended practice. > a single leaked private key means your entire site is compromised The leak is the actual vulnerability. As long as the leak is still there and you are not aware of the compromised private key, a fresh new private key will probably leak again. However, the chances of leaking may be greater if a private key has to be used in multiple locations.

toast0 3y ago

Pinning the site cert (or its key) is not great because it makes it very hard to rotate your certificate or key. And you've got to be able to do that, in case your key is disclosed or possibly disclosed. Pinning intermediates doesn't make a lot of sense; unless you have a deep relationship with the CA, they can and do change intermediates, and may not be able to issue from the old intermediate after the change. But, I've been involved in cert pinning where we had to pin intermediates, because that's the only viable information the client API returned we could use for pinning (and really, it was pinning based on the name of the intermediate --- any system trusted Root CA could have made an intermediate specifically to bypass our pinning, but it was the best we could do on that platform; of course, this was also the platform where we ended up with a wrong pin in our final build (platform owner shut down their app signing CA), which meant some ugly workarounds). Pinning roots makes sense, but you need to pin more than one. And roots from more than one organization. And you need a succession plan. You can't use a new root on an existing hostname until all of the deployed clients with pins that could use that hostname have become irrelevant. If your all your trusted CAs stop issuing, you're pretty screwed. You can sometimes use an in-house root, which makes continuity easier, but not if you need to share hostnames with browsers. You can't get an entity cert signed by two issuers, so there's no way to present a cert that is trusted by browsers and also signed by your root. You can present alternate paths for the issuers of your cert (and any intermediates) and if the x.509 libraries do the right thing, any valid path is accepted; but not all libraries do the right thing, and again, that doesn't apply to the entity cert.

jcalvinowens 3y ago
Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.
- toast0 3y ago
  Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to the system root store and intercepts traffic with the intent of passing it through but does not do so correctly and causes hard to diagnose errors. A pinned cert makes it easy to detect these MITMs and refuse to work if they're in place. A dedicated reverse engineer is "just" going to patch out the pin, and go on with their day, no big deal. But ISP MITM or corporate MITM or on device MITM is going to be stopped, and that's worthwhile.