This sounds like a serious issue, and I wouldn't be surprised if news will come out soon about an app that allows for a massive security breach because it didn't use the root store correctly.
S/MIME and HTTPS are quite different types of services, the former still usually relying on long-lived certificates whilst the latter is moving to shorter and shorter certificate validity, lessening the impact of a breach. Using S/MIME certificates to validate TLS might even allow a website to use the certificate of some random email address in your company to do a man-in-the-middle attack on your certificate, if the app's implementation was written badly enough.
--
Offtopic: speaking of root stores and Mozilla, I'm still miffed about Firefox's decisions about the subject on Android. They removed the old root certificate management/installation pages, put a switch to enable the system's user certificate store in about:config and then removed the ability to use about:config from the stable release of Firefox for Android.
I've seen a commit message saying that they moved the setting to allow the certificates the user explicitly installed on their system to work inside Firefox into a secret developer menu. I found that thread because I was looking into why my phone would randomly reset the about:config setting every day (because of a bug? because of the change? who even knows).
My intranet websites work on pretty much every browser other than Firefox on my phone. It's really annoying.
It used SSL/TLS and S/MIME roots to verify code signing and timestamping responses. When Symantec, which was removed for TLS trust, was also removed for S/MIME, NuGet broke, because it was no longer able to verify the TSA signature.
Any application using the ca-certificates package thus end up trusting CAs that Mozilla does not trust, despite being derived from the Mozilla Root Store.
So the news is already out there, this was just a reminder to folks to not do silly things like Microsoft did.
Please stop breaking the site guidelines like that. I'm sure you wouldn't think of littering in a city park or starting fires in trash barrels, so please don't do the equivalent here.
This situation is the same on Android, presuming you do not have a rooted device. On Android >7 third-party apps do not trust user certificates by default, and a non-root user cannot install new system certificates. And afaik there is nothing stopping them from using custom crypto libraries that do not use the system roots at all. And of course, even if you could decrypt the HTTPS traffic the actual API payloads and endpoints need not be in any kind of human readable format.
Well they could prohibit it if they wanted. They could even require that apps provide a method to inspect traffic. They never will though, because cert pinning is good for security, and any user-accessible method to access secrets becomes a target for phishing or other social engineering.
That would certainly be the day I go "what the heck, Apple/Google." They could certainly try and prohibit it, but I don't think the backlash would bode well for them, and we'd only see people obfuscating their traffic even more.
It does suck and it's a tradeoff of security/privacy. But it's not impossible, you just need to try a bit harder. If you have a jailbroken phone (the latest jailbroken version can almost always run every modern app), it's easy to install iOS SSL Kill Switch. If you don't have a jailbroken phone, you can wrap the app in your own certificate and side load it with hooks that disable the SSL routines.
I think the underlying problem is that the apps stop talking because the certificate validity check fails when traffic is proxied through your MITM. No MITM proxy can make that succeed, but if you can control the CA store that apps read, then you can create a certificate, add it to the trusted roots, use that cert to sign a certificate for someone else's website, and then when the app uses the system library to verify the validity of the certificate, it will appear valid, even though it's not. Without being able to hack the certificate verification, you can't MITM traffic between two devices you own. I think that's the complaint the grandparent has.
Apps can still pin certificates, of course. At that point, you have to exploit the app's other faulty assumptions like "I'm running the same code that the compiler produced" or "writing 0 to memory address 0x12344321 and then reading memory address 0x12344321 will result in reading 0", which are straightforward to make false. Though probably not on a stock iPhone.
I would bet that > 75% of the top 50 apps use SSL pinning. Apple makes it really easy to do and it's an obvious first defense against reverse engineering.
What happens is that apps don't work if their cert is issued by another CA, eg. "we only use digicert so any other CA issuing us is either attacking us or a enterprise/hobbyist MITM which we don't care about anyways".
> Additionally, some application developers directly parse a file in Mozilla’s source code management system called certdata.txt, in which Mozilla’s root store is maintained in a form that is convenient for NSS to build from. The problem with the scripts that directly parse this file is that some of the certificates in this file are not trusted but rather explicitly distrusted
Could the file be split to retroactively fix everyone doing this?
Sure, but some distros (read: Fedora that I know of) use this as a source of truth for their TLS Root trusts. Means the scope is larger than just Mozilla and they'd (hopefully) coordinate with downstreams and others prior to changing this.
Best would be if they shipped a reference parsing library for whatever format they do use is. :-)
Cryptosystems are hard. I've been thinking a lot lately about cryptosystems, and my thinking is that there's entirely too much complexity in this space: What works is keeping things simple.
RE: CA Lists: Your CA list should be as short as it can be. The public CA list should be the public CA list, and you should use Mozilla's HTTPS list or Google's Chrome Root Store... but these lists are public lists for public infrastructure, and what you should use for communicating with services you don't control.
Every company should have a CA. Possibly every division of every company. Don't throw them all in the same file. You should, as a client, make use of TLS Contexts: You should specify for every HTTPS Client a specific CA, which for internal services should be your own CA.
As a server, client certificate auth is pretty rare (but it shouldn't be). When you do have it, you don't always have control over the client's root CA, but you shouldn't blindly trust it, either. You must verify that the claims on the client certificate match the claims on the CA, but also that the claims on the CA match your actual trust of the CA. The latter shouldn't be done at runtime, but during configuration. You shouldn't accept blind root signing certificates; You should accept from your clients intermediate CAs with appropriate constraints baked in.
This brings into the equation another important problem: You shouldn't have complex claims on client certificates.
I'm watching closely the SPIFFE project [1], which I believe is well intentioned but don't believe has got it right. I've also got my own project, KubeTLS[2] which implements a simple claims system - Which is appropriate in very limited constraints, but I believe those constraints also match most businesses real-world needs.
I feel like I'm missing some context here - they say applications are using the Mozilla root store "for purposes other than what Mozilla’s root store is curated for", but they never actually say what those purposes are. I wonder if they don't think it matters or if they're being deliberately secretive because there's an unpatched exploit floating around somewhere? That said, I can't come up with what somebody could be using a root store for besides validating a certificate.
"Purpose" refers to the type of certificate, e.g. SSL/TLS certificate, S/MIME certificate, code signing certificate.
Some roots in Mozilla's store are trusted for TLS only, some for S/MIME only, and some for both. The blog post is about applications which are using Mozilla's root store to verify certificates which are for a different purpose than the root is trusted for.
For example, NuGet uses Mozilla's root store to verify code signing certificates, which is obviously wrong because none of the roots in Mozilla's store are trusted for the purpose of code signing: https://github.com/NuGet/Announcements/issues/56
From the article, one use case they explicitly call out is code signing verification.
Parties like Apple use x509/PKI certificates for code signing. A third-party application COULD use this trust DB for code signing verification. If an application is signed with a (root) cert trusted by this DB, it is allowed.
Mozilla is saying woah: we only validate CA's TLS Server and S/MIME requirements (for CAs in our root DB). They don't validate that an arbitrary CA in their root DB has proper code signing certificate issuance procedures. So this theoretically application is in the wrong and they consider it a high severity vulnerability.
But I agree, there's an open question about _who_ is using the DB this way.
There likely is an unpatched exploit that Mozilla is aware of but isn't disclosing (to the public). I'd hazard a guess it's more related to blindly parsing the root store and trusting the certs that Mozilla has in there specifically for the purpose of not trusting them (DigiNotar, et. al).
I think I'm missing some understanding. Does this include companies like Netskope that inject themselves into a systems root trust chain to MITM TLS communication?
No, I don't think it's about apps modifying the root store used by Firefox.
Rather, it's about well-intentioned apps using Mozilla's root store in their own https client, but doing it incorrectly so they don't get the security guarantees they think they are getting.
S/MIME and HTTPS are quite different types of services, the former still usually relying on long-lived certificates whilst the latter is moving to shorter and shorter certificate validity, lessening the impact of a breach. Using S/MIME certificates to validate TLS might even allow a website to use the certificate of some random email address in your company to do a man-in-the-middle attack on your certificate, if the app's implementation was written badly enough.
--
Offtopic: speaking of root stores and Mozilla, I'm still miffed about Firefox's decisions about the subject on Android. They removed the old root certificate management/installation pages, put a switch to enable the system's user certificate store in about:config and then removed the ability to use about:config from the stable release of Firefox for Android.
I've seen a commit message saying that they moved the setting to allow the certificates the user explicitly installed on their system to work inside Firefox into a secret developer menu. I found that thread because I was looking into why my phone would randomly reset the about:config setting every day (because of a bug? because of the change? who even knows).
My intranet websites work on pretty much every browser other than Firefox on my phone. It's really annoying.