New Intermediate Certificates
letsencrypt.org
letsencrypt.org
Sometimes also "some user will look at the network traffic and notice that we have 0 server-side security".
[1] https://en.wikipedia.org/wiki/Superfish#Lenovo_security_inci...
If you're talking about someone wanting to examine an app they have installed, there's nothing a developer can do about it.
There are frameworks like Frida that allow you to disable pinning or disable certificate verification entirely in an app. I did this myself once while reverse-engineer the API that an app was using. Configured my phone's system proxy to point to Burp Suite, then used Frida to disable certificate verification in the app so it'd let Burp do its MitM magic, and I could see all the app's network traffic.
I think what this means is, if you're needing some stricter limitations on these, use private PKI within your own devices. E.g. for Machine to Machine comms.
While we don't recommend key pinning, there's nothing to prevent pinning Let's Encrypt's root CAs.
(I work for Let's Encrypt)
Generally, a root is trusted by virtue of being in your root store and can't be revoked via OCSP/CRLs. An operating system security update should remove distrusted roots.
The mainstream browsers all have a push-based mechanism that they can use to rapidly revoke a root or intermediate faster than that. If something truly bad happened, Let's Encrypt would ensure that happened ASAP.
However, many clients do no revocation checks at all. That's a big part of why the ecosystem is pushing to shorter lived certificates, intermediates, and roots.
Exactly what clients do about revocation for Intermediates and End Entity certificates varies, the revocation information will be available publicly in one (or both) of two forms:
The Online Certificate Status Protocol. OCSP results have a lifetime so you can check back periodically, and they're created via a distinct key from the Root, which has its own certificate (provided in the response) showing that it's trusted to do this specific work.
Certificate Revocation Lists are signed documents with a list of revoked certificates. CRLs are again signed using a distinct key with its own certificate showing that it was authorised to sign these lists.
Some client vendors may (semi)automatically aggregate information to produce their own summaries so that their clients can rely on the aggregate rather than fetching revocation information during use.
OCSP in particular was designed so that it could be stapled which is a technique where your server fetches and then includes the OCSP results for your end entity cert (and possibly the intermediate) with the cert itself during a connection handshake, the client thus now has a valid (albeit perhaps not entirely fresh) OCSP answer without doing its own checks, since OCSP is signed you can't forge this although of course if you have a 48 hour OCSP good answer you could continue playing it for up to 48 hours even if subsequent OCSP results said revoked.
Unfortunately implementation for OCSP stapling has been fairly poor, it's usually wrongly or at least badly implemented by people who apparently have no idea what the goal was and so it can make your service needlessly less reliable if your server is defective in this way, so the main browsers are not (last I knew) much interested in pursuing this further.
Of course, you might consider that a legitimate employer thing to do.
Although IMHO saying "don't pin this cert which expires in 2027, instead pin this cert which expires in 2035" is kinda a weird distinction to make as those are both too short.
Pinning an expired cert means you are 100% sure the software won't work.
(I do agree cert pinning is bad overall.)
1. All-powerful NSA types who've managed to steal a CA's private key or get a certificate mis-issued. It's a nigh-irreplaceable attack opportunity, but the moment they use it it'll be revoked within hours, so naturally it's reserved for the absolute highest value target. For example, [1]
2. Users trying to reverse-engineer your app.
You can imagine which of these is the most common - perhaps you don't want the user to be able to bypass the pin, even intentionally.
[1] https://www.eff.org/deeplinks/2011/08/iranian-man-middle-att...
Just please don't pin intermediate CA keys, which should be opaque to the end-user and need to be able to change quickly without breaking a bunch of apps.
Please don't pin roots, as that makes it harder to distrust CAs, reducing the agility of the WebPKI. See the Symantec distrust for a painful example.
Chrome and Firefox will be introducing term limits on roots in the near future, which will hopefully help to discourage this harmful practice.
So what would be the recommended way to protect against government MitM by using some obscure CA?
https://certificate.transparency.dev/
Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted.
At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.
That's adequate for low-value targets, but it's hardly sufficient for high-value targets. If a CA mis-issued a cert for *.aws.amazon.com should we be waiting around for a manual process on some mailing list to invalidate it?
But the CT system seems to work very well in practice. While the detection and remedy part is awkwardly manual, there are people working hard on them. There are also (following a "you have to disclose all intermediates ahead of time" rule introduced by Mozilla) fewer intermediates and we actually have a list of them.
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRe...
Detected incidents involving intentional misissuance are very rare. When unintentional misissuance happens, the responsible CA has to publicly explain how it happened and what it will do to prevent the situation from happening again.
Also, how do you detect "obscure" CAs in the log? If your CT monitoring daemon has some logic to distinguish "good" from "bad" CAs, why not use that logic directly in the app and implement certificate pinning?
Root / Intermediate / Server, you only pin server certificates and not the levels above them.
The reasoning goes like this. Roots represent entities you trust (or in most cases, which are trusted on your behalf by some entity that's thought about what constitutes trustworthiness e.g. your browser vendor, OS vendor, or maybe your workplace). Accordingly the root "certificates" aren't really certifying anything, the X.509 certificate format is a convenient structure to put this data in, but unlike most certificates they don't represent a certification of anything by anybody, in human terms these documents tend to say e.g. "We, ISRG claim that we are ISRG and we're a Certificate Authority and we're signing this document to say so". OK, but anybody could make such a self-signed document, there's no way to "authenticate" them, you must have decided to trust some of these claims (or as I said, your vendor probably did for you)
The private key corresponding to a root is therefore very precious, billions of people trust signatures made with this key so it's a huge deal if it's stolen/ compromised. As a result we require that these keys aren't online, they're typically manifested as a small physical object (a "hardware security module") locked in a safe, the idea is that the key itself cannot easily leave the object, so by locking it in a safe we've protected the key.
But since these roots can't be online, we can't make certificate with them online, so a simple system of the sort you might build at work, with a CA root that directly issues certificates, isn't possible. This is where the Intermediates come in.
A ceremony is conducted, with third party auditors and senior personnel from the CA to watch as the Root is used to sign one or (as here for ISRG) a handful of Intermediate certificates. These documents can usefully be verified because they were signed with the Root's keys, if we trust a Root we can check that indeed it has signed this Intermediate. The CA is also required to have a technology so that it can (in a reasonable amount of time) revoke an intermediate if for example it was compromised or stolen.
Unlike a root, the Intermediates can then be kept online (at ISRG only some are used this way, others are just backups against the unexpected) and used to sign End Entity (what you've called Server) certificates in real time shortly after they are ordered, once the appropriate checks have been carried out. HSMs are used again, but in this case they're attached to a server where the issuance software is running rather than locked in a safe.
This post is about ISRG using new Intermediates.
That means that you need to hard-code the public key of the certificate that you're using in the client application. That certificate might be signed by letsencrypt or any other CA, it doesn't matter. If you're pinning CA key, you put trust into entity which you don't control. They can replace any of their keys. They can stop signing your certificate. It makes little sense to pin CA certificates.
Just make sure to have a plan for key rotation in case you need to revoke your key.
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.
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.
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.
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.
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.
Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.
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.
If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point?
If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames.
> If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
That comes from HSTS, not from cert pinning. Cert pinning in browsers is only available if you can convince the browser to include it in their static lists, which means you've got to be big... so that is what it is.
As an aside - this isn't generally very effective or worthwhile nowadays.
Anybody doing reverse engineering at a level where they're installing their own system certificates & intercepting traffic can easily run many off the shelf scripts (Frida scripts, Objection, apk-mitm, etc) which will disable certificate pinning like this automatically. This takes _seconds_ to disable and is standard practice.
Even doing so manually is not especially difficult - the pin is fairly predictable value, and a reverse engineer can access all content of the mobile app, so can easily search for and just replace it before installation.
From a reverse engineering perspective, there's little-to-no value in purely client-side protections like this. You're not increasing the reverse engineering difficulty significantly and you do create many practical problems with e.g. certificate rotation in future.
OTOH there is an interesting case to be made for certificate pinning as a protection for users being unknowingly MitM'd. That's a different scenario that may well be worth defending against, but due to the many downsides of cert pinning, using certificate transparency to mitigate this is strongly preferable nowadays.
In contrast, with a non-pinned app, you can monitor traffic of that app as it is installed right now.