Chrome on ChromeOS has had its own trust store for ages. Chrome on Android similarly uses Google’s Android store.
454 karma · joined September 21, 2012
It is elegantly complex and featureful. And (sometimes intentionally) poorly documented, as much of that implementation is seen as “an implementation detail”.
I’ll be the first to tell you that I believe Google and Mozilla have done a lot for supervising TLS, but realize that the trust stores contain many other non-TLS purposes, and with the CAs constrained from TLS issuance (e.g. only trust for S/MIME).
CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab
You can see a little bit about this at https://github.com/crtsh/certwatch_db/issues/69 and http://unmitigatedrisk.com/?p=259
Approaches like the OP link fail to take that into consideration, and can easily break core OS services, non-TLS cases like code signing or S/MIME, or even reintroduce trust in CAs that Microsoft has programmatically disabled.
Unfortunately, just like captive portals want to avoid detection by your OS [*], the vendors of these devices want to do the least possible work, for the lowest possible cost, never updating or supporting the device once sold. Any new solution is more work for them, especially early on when things are still in development/in flux and may require changes over time, since the problems in this space are actually rather difficult.
It’s not that this problem isn’t important, but rather that there’s no clear good path here. However, even still, the alternative (of HTTP) is much worse for the Web, so TLS is still promoted aggressively.
[1] The reason captive portals want to avoid OS detection is because the OS-spawned UI generally doesn’t have access to your browser cookies. The ecosystem has mostly ossified around a few captive portal vendors, who want your cookies either for advertising/demographics/traffic, or want to offer “Sign in with Social Network” (to both track and... advertising). So they want you to use your main browser, not the OS UI, and thus want to actively avoid OS detection. It’s sad.
The WebAuthN case in particular is quite unfortunate, and one I tried to discourage early on (along with the whole app facets approach)
To the extent it is used by cookies, we still want to maintain a fair and equitable solution. However, we also want to actively discourage any new users or use cases, to the extent possible, while we also try to fix cookies.
Ideas like https://github.com/privacycg/first-party-sets provide a possible model. While FPS doesn’t directly address this, as part of keeping a narrow scope, the approach to explicitly expressing boundaries is one that has the best viable path. However, that’s effectively “Deprecate the Host option for cookies”, so... that’s a big task.
Simply sabotaging the PSL doesn’t force the problem to be solved, so mostly, it’s an education campaign of “We made a mistake; learn from ours, rather than repeating it.”
Is actually hard to implement correctly and interoperably, even among browsers, and there are sharp edge cases along the way (such as holes within domain trees).
The author of the library referenced at least worked with the PSL maintainers and browsers to make sure they were faithfully and correctly implementing things :)
Countries view ccTLDs as their sovereign property and territory on the Internet, and refuse to be (involuntarily) bound to any rules or requirements as a matter of sovereignty. It’s a huge source of geopolitical conflict within the IANA/ICANN split (and with DNS in general).
A number of countries have _voluntarily_ agreed to follow ICANN’s principles for good management and interoperability [1], but jurisdictions gonna jurisdict I guess.
Which is to say: things went wrong in circles because different folks had different problems, those different problems had incompatible requirements, and so things spun in circles for a number of years as every idea failed to solve the problem for everyone simultaneously, while narrowly-specified solutions were shot down for not solving enough problems.
Yes, it’s weird to have a maintainer asking people not to use their project, but the PSL was a very specific (and unfortunate) hack for a very specific (and unfortunate, and browser-created) problem. It is something we live with, not something we like. While the ideal world is “don’t use any list at all, use the protocols as God, the IETF, and IANA intended”, if you are going to use a list, using the IANA list, updated daily, is much better than the PSL.
Do not use the PSL for anything that is not “cookies abusing the Host header”
Read the Roadmap at https://ec.europa.eu/info/law/better-regulation/have-your-sa... and comment on the Public Consultation if you have feelings about that.
Explicitly part of the goal is either a pan-European ID card or requiring every Member State to adopt one. Currently, MS aren’t required to. When the UK was in the EU, the idea of a digital ID that could be used by the government to track all of your activities online was... not popular. However, despite Brexit, the idea is being reintroduced, this time to “fight coronavirus”. https://www.bbc.com/news/uk-politics-54010432
Any HTTP/ALPN request first begins with DNS, so if you’re trying to compare those, they all share the same base issue. In theory, this can be mitigated by DNSSEC, but that’s not relevant when comparing these validation methods.
However, both the HTTP and ALPN methods only demonstrate control over a single port (or .well-known resource), while the DNS method demonstrates the full ability to alter any/all names.
CAs are required to run full recursive resolvers, up to the root, and can’t just point at someone else’s DNS infrastructure. Which, if you think about it, is what you want: you don’t want the CA just trusting someone else is being honest, you want to go to the authoritative source.
However, in practice, the DNS challenge (which demonstrates control over DNS) is greatly preferred over HTTP/TLS challenges (which demonstrate control over a single port).
DNS is likely to be the only way to get a wildcard certificate, and HTTP/TLS will likely end up further restricted once SRVNames in certificates can be gracefully rolled out.
As such, deploying the DNS based control is absolutely the best thing to do, and HTTP/TLS should be seen as legacy-compat fallbacks that may become more difficult in time. Either certificates become less scoped than “entire domain” (as they are today with dNSName SANs) or it becomes more difficult to use a single port to prove authorization for an entire domain.
Stories like this are stories like those mentioned in the post: everything on the Internet is awful, and you work with what you have and work around things by adding JPEGs of cats and silly session IDs (As TLS 1.3 does) and whatever it takes to “make it work”.
DoH/DoT, if it’s able to be adopted before ISPs and middleboxes ossify it with subpar implementations as part of their effort to avoid net neutrality ( https://www.theverge.com/2019/10/4/20898779/fcc-net-neutrali... ), is the first time in a long time that innovation and experimentation in DNS might happen again. This is why we see things like ESNI and SVCB ( https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc ) having a chance at being deployed. At least, if clients can get there before the middleboxes ruin the party, like they’ve tried to do for QUIC.
Google has a healthy Patch Rewards program ( https://www.google.com/about/appsecurity/patch-rewards/ ) that rewards patches to a variety of Open Source Projects.
Google also finds a variety of projects through the Core Infrastructure Initiative ( https://www.coreinfrastructure.org/ ), which OpenSSL is part of https://www.coreinfrastructure.org/announcements/the-linux-f...
A healthy root store would set revocation at a much more aggressive period; say, every five years. Every three years, the CA applies to have their new root trusted, which gives two years to distribute that root to clients that need it, while having the old root sign the new root, to support an immediate transition to the new root. Among other things, this encourages a more robust and healthy CA ecosystem, because you don’t end up with lopsided balances based on “who has the oldest root.” That imbalance encouraged poor behavior which got CAs distrusted, in the past, because they behaved in a manner that assumed they were too big, by virtue of being too ubiquitous, to fail.
It’s not either/or expiration vs revocation; they are the same thing. Expiration is natural revocation and a ceiling function to the overall cost.
The statement “when a CA’s root certificate expires, it creates a new one” is not a general statement. That’s the exception, rather than the rule, as evidenced by just watching the changes to root stores over the past 30 years. More CAs have left the CA business / folded / been acquired than have carried on. A classic example of this is the AOL root, for which the long-standing scuttlebutt is that no one knows what happened to the key after AOL exited the CA business. The reason it’s scuttlebutt, as opposed to being a Sky is falling DigiNotar, is that the certificate expired. Or, for that matter, look at how many CAs have been distrusted. Expiration fits as a natural bound for legacy software that doesn’t receive updates, failing-secure rather than failing insecurely.
Expiration is not “just” about cryptographic risk either; there are plenty of operational risks. If you’re putting your server on the Internet, and exposing a service, you should be worried about key compromise, whether by hacker or by Heartbleed. Lifetimes are a way of expressing, and managing, that risk, especially in a world where revocation has a host of failure modes (operational, legal/political, interoperability) that may not be desirable.
As for Root expiration, it’s definitely more complicated than being black and white. It’s a question about whether software should fail-secure (fail-closed) or fail-insecure (fail-open). The decision to trust a CA, by a software vendor, is in theory backed by a variety of evidence, such as the CA’s policies and practices, as well as additional evidence such as audits. On expiration, under today’s model, all of those requirements largely disappear; the CA is free to do whatever they want with the key. Rejecting expired roots is, in part, a statement that what is secure now can’t be guaranteed as secure in 5 years, or 10 years, or 6 months, whatever the vendor decides. They can choose to let legacy software continue to work, but insecurely, potentially laying the accidental groundwork for the botnets of tomorrow, or they can choose to have legacy software stop working then, on the assumption that if they were receiving software updates, they would have received an update to keep things working / extend the timer.
Ultimately, this is what software engineering is: balancing these tradeoffs, both locally and in the broader ecosystem, to try and find the right balance.
At the core, this is not a problem with the server, or the CA, but with the clients. However, servers have to deal with broken clients, so it’s easy to point at the server and say it was broken, or to point at the server and say it’s fixed, but that’s not quite the case.
I discussed this some in https://twitter.com/sleevi_/status/1266647545675210753 , as clients need to be prepared to discover and explore alternative certificate paths. Almost every major CA relies on cross-certificates, some even with circular loops (e.g. DigiCert), and clients need to be capable of exploring those certificates and finding what they like. There’s not a single canonical “correct” certificate chain, because of course different clients trust different CAs.
Regardless of your CA, you can still do things to reduce the risk. Using tools like mkbundle in CFSSL (with https://github.com/cloudflare/cfssl_trust ) or https://whatsmychaincert.com/ help configure a chain that will maximize interoperability, even with dumb and old clients.
Of course, using shorter lived certificates, and automating them, also helps prepare your servers, by removing the toil from configuring changes and making sure you pickup updates (to the certificate path) in a timely fashion.
Tools like Censys can be used to explore the certificate graph and visualize the nodes and edges. You’ll see plenty of sites rely on this, and that means clients need to not be lazy in how they verify certificates. Or, alternatively, that root stores should impose more rules on how CAs sign such cross-certificates, to reduce the risk posed to the ecosystem by these events.
Some ccTLDS voluntarily agree to abide by the same rules and operational requirements as the gTLDs - https://www.icann.org/resources/pages/cctld-2012-02-25-en has more details.
This means, for example, than ccTLDs aren’t bound by the findings from SAC053 at https://www.icann.org/en/system/files/files/sac-053-en.pdf which have been included in the gTLD contracts.
Like most things, on first glance, it seems like it does make sense. Except it has a lot of issues, which you can see have been discussed for 15 years without resolution, even though yes, it would scale better.
The answer is that we should build better routing into OpenSSL - and all the other PKI-validating products. It's complex and complicated, but if you only have a very narrow and particular purpose (e.g. just care about TLS), then you can get away with it with rather a little amount of code, as Mozilla's mozilla::pkix shows - https://blog.mozilla.org/security/2014/04/24/exciting-update...
But even if we were to change all systems tomorrow, that affects only the upper 10% or, to be generous, 25% of PKI clients (nb: numbers pulled out of my ass, but it's an experienced ass). We still have a LONG tail of systems running OpenSSL, earlier versions of Windows, or any number of custom solutions, and they support SHA-256 but won't ever be updated again. So stopping SHA-1 actually protects them, and is the only thing that CAN possibly protect them, and that's why LV is such a hard trade-off: we give up the protections for a large chunk of users, in order to regain access to a small group.
And that's ignoring that the data quantifying the size of the small group, or _why_ the small group exists (to see if there are other levers or alternatives than "replace device" and/or "keep issuing SHA-1" exist. Luckily, Jan 1 isn't going to be some SHApocolypse - 39 month certs issued on Dec 31 2015 will remain valid well into 2019, so there's time to have a reasoned, data-driven debate about "old-old" clients, "new-old" clients, and "new-new" clients.
Certificate verification stops when you encounter a TA. Some libraries do the wrong thing and check that the terminal cert is self-signed, but that's not actually required (nor recommended). You just check that the previous cert is signed by the TA, which involves checking the previous cert's signature (aka the intermediate) with the trust anchor's key.
That's why the trust anchor's signature is irrelevant.
See RFC 6024 for a discussion of terminology and concepts.
We have looked at it. Repeatedly. First when porting Chrome to Linux (and trying to decide what sort of UI there should be for NSS cert management). Then for ChromeOS. And then again, revisiting it in light of the OpenSSL migration.
The reality is, the certificate management/configuration UIs, of all platforms (Windows, OS X, Linux-via-Firefox-and-Chrome-which-just-copies-Firefoxes-PSM), is hard. It's hard to express the decisions. It's hard to explain how the branching and cross-certifications of CAs can affect trust decisions (eg: recall DigiNotar's cross-certifications).
And in the end, it's not where users are spending their time/being tripped up. Getting the lock icon into a more meaningful state is a far, far greater investment, with far, far more actionable returns in users security. The work of the Chrome Security Enamel team on this - especially Adrienne Porter Felt - has been focused on trying to improve this.
However, I think you're doing a disservice if you only look at how easy it is to add code. As important is how easy it is to remove code. With NSS, it's far, far harder to remove code - and that makes it far, far harder to reason about any new code you might want to add, for who knows what grues are lurking in those shadowy depths.