Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
It's important to note that this is preventing pinning /intermediates/ which are re-issued about annually. It is usually a mistake to do that. It is possible that due to a large-scale incident, we'd have to revoke an intermediate immediately and switch to a backup.
While we don't recommend key pinning, there's nothing to prevent pinning Let's Encrypt's root CAs.
It's specifically to discourage intermediate key pinning. If folks want to pin their own end-entity public key (and always re-use the same key when renewing their cert), go for it -- dealing with compromise of their own key is their own problem to solve. Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it (although that doesn't prevent a bad actor from getting the same CA to issue a MITM certificate; there are other mechanisms to prevent that).
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.
> This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
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.
You should be able to fully inspect all traffic originating from your device and reverse-engineer everything running on it, so any change that makes it harder for others to stop you from doing so is a good one.
> 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.
They're mainly trying to issue certs for public facing websites. If your service is in a position where someone can install an alternative root CA on your webserver, you're already pwned!
Does this not simply mean they want people to pin "ISRG Root X1" instead of pinning "Let’s Encrypt R10" because they want the ability to rotate the latter?
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.
[+] [-] phantom784|2 years ago|reply
[+] [-] mcpherrinm|2 years ago|reply
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)
[+] [-] phasmantistes|2 years ago|reply
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.
[+] [-] pimterry|2 years ago|reply
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.
[+] [-] josephcsible|2 years ago|reply
[+] [-] jcalvinowens|2 years ago|reply
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.
[+] [-] ijustlovemath|2 years ago|reply
[+] [-] michaelt|2 years ago|reply
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.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] dist-epoch|2 years ago|reply
Of course, you might consider that a legitimate employer thing to do.
[+] [-] vbezhenar|2 years ago|reply
[+] [-] withinboredom|2 years ago|reply