31–40 of 57 posts
Earlier quoted context omitted.
I kinda wish pins by default became unpinned when the pinned cert expired. Pinning an expired cert means you are 100% sure the software won't work.
What prevents the user from simply setting their clock forward? (I do agree cert pinning is bad overall.)
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. (I work for Let's Encrypt)
Earlier quoted context omitted.
> Please don't pin roots So what would be the recommended way to protect against government MitM by using some obscure CA?
Currently CT logs: 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.
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.
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.
Earlier quoted context omitted.
Currently CT logs: 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.
An adversary might MITM the CT as well.
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.
Maybe get a proper certificate designed for such things instead of using what amounts to a corporate-funded public service.
Earlier quoted context omitted.
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!
The threat model isn't "someone will install stuff on our servers". The threat model is "some user will look at the network traffic and see all the personal data we're hoovering from their phone". Sometimes also "some user will look at the network traffic and notice that we have 0 server-side security".
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.
Earlier quoted context omitted.
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,…
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.
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.
Earlier quoted context omitted.
Maybe get a proper certificate designed for such things instead of using what amounts to a corporate-funded public service.
Indeed, many of the vendors who will sell you proper certificates will also sell you anti-tiger rocks, which you should also consider procuring.
Earlier quoted context omitted.
Maybe get a proper certificate designed for such things instead of using what amounts to a corporate-funded public service.
What is improper about them? Works for 100% of my use case, well known, trusted, compatible.