How to distrust a CA without any certificate errors

https://dadrian.io/blog/posts/sct-not-after/

by tptacek • 1 year ago

173 93 1 year ago

mcpherrinm2• 1 year ago

The flipside of the same technical points is https://sslmate.com/blog/post/entrust_distrust_more_disrupti... where some non-browser clients don't handle this, or worse, handle it incorrectly.

tptacek16• 1 year ago

Right; it's imperfect, as everything is. But of course, it's also a huge bit of leverage for the root programs (more accurately, a loss of leverage for CAs) in killing misbehaving CAs; those programs can't be blackmailed with huge numbers of angry users anymore, only a much smaller subset of users. Seems like a good thing, right?

LegionMammal9783• 1 year ago

Only insofar as you trust the root programs to use their leverage responsibly, both today and in the medium-to-long-term future.

Y_Y• 1 year ago

Right; it's imperfect, as everything is.

Is this tautology helpful? For sure it's commonly used, but I honestly have a hard time seeing what information it conveys in cases like this.

dadrian6• 1 year ago

Non-browser clients shouldn't be expected to crib browser trust decisions. Also, the (presumably?) default behavior for a non-browser client consuming a browser root store, but is unaware of the constraint behavior, is to not enforce the constraint. So they would effectively continue to trust the CA until it is fully removed, which is probably the correct decision anyway.

DSMan195276• 1 year ago

To me that's an odd position to take, ultimately if the user is using Mozilla's root CA list then they're trusting Mozilla to determine which certs should be valid. If non-browser programs using the list are trusting certs that Mozilla says shouldn't be trusted then that's not a good result.

Now of course the issue is that the information can't be encoded into the bundle, but I'm saying that's a bug and not a feature.

bigiain• 1 year ago

Hmmmm, speaking of distrust and Mozilla...

I wonder how much I should be concerned about Mozilla's trust store's trustworthiness, given their data grab with Firefox? I've switched to LibreWolf over that (more in protest than thinking I'm personally being targeted). But I'm pretty sure LibreWolf will still be using the Mozilla trust store?

I haven't thought through enough to understand the implications of the moneygrubbing AI grifters in senior management positions at Mozilla being in charge of my TLS trust store, but I'm not filled with joy at the idea.

dadrian6• 1 year ago

What actual risk are you worried about here? Mozilla changed their data policy, therefore the root store might do what...?

chicom_malware2• 1 year ago

WebPKI is a maze of fiefdoms controlled by a small group of power tripping little Napoleons.

Certificate trust really should be centralized at the OS level (like it used to be) and not every browser having its own, incompatible trusted roots. It's arrogance at its worst and it helps nobody.

lxgr11• 1 year ago

tl;dr: By using the CT logs as a trusted timestamping service, if I understand it correctly?

tptacek16• 1 year ago

More broadly, because longstanding universal adoption of CT makes it possible for root programs to grandfather in older certificates, so that they can axe a CA without generating SSL errors for all that CA's existing certificates, which is something they couldn't do before.

peanut-walrus• 1 year ago

By far the most logical default behavior to me is that if the issuing CA was valid and trusted when the cert was issued, the cert should be considered valid until it expires. This of course means you need a trusted timestamping service or I guess CT can fulfill the same purpose.

For CAs who get distrusted due to reasons which imply their issued certs might not be trustworthy, either revoke the certs individually or use a separate "never trust" list.

zahllos• 1 year ago

This is what is done for code and document signing, because you want the signed object to continue to be valid even after the certificate expires.

However it has a tradeoff: you cannot remove any certificate from a CRL if revoked, ever. Under normal circumstances certificates naturally expire so only need to remain in CRLs if revoked before then, but with timestamps they are valid indefinitely so must be explicitly marked invalid.

cryptonector6• 1 year ago

The better thing to do for this case is to only check the code signing certificate's validity at install time rather than every time you run the code. Then you don't have to have boundlessly growing CRLs. In general checking code signatures at run-time is just a perf-killing waste of resources. Ideally secure, measured boot would also measure the OS filesystems you're booting, and that kinda requires a content-addressed storage copy-on-write type filesystem such that you can seal boot/keys to a root hash of the root filesystem, but here we are in 2025 and we don't quite have that yet. ZFS comes closest, though it's not a CAS FS, but somehow the last mile of this never got implemented by anyone in any operating system.

egberts13• 1 year ago

CT is a temporary glue until the keyless Signal protocol takes over TLS.

lxgr11• 1 year ago

What protocol are you referring to?

tptacek16• 1 year ago

Before I log into Citibank I can just verify their safety number out of band.

permo-w• 1 year ago

I’m not sure I see the point of these certificates in the first place. you can get literally any website certified in 5 minutes

bell-cot• 1 year ago

This is often cited as the reason (but there are plenty more):

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

If the CA's are doing their jobs...then FirstBank.com can get a cert for their web site. But the gang who rooted a bunch of home routers (or hacked a WiFi setup, or whatever) can't.

If not...then yeah, that's the problem.

sybercecurity• 1 year ago

True - the purpose was to authenticate, not just encrypt. Years ago, every CA had additional tiers of authentication for certificates that included all sorts of ID checks, corporate records, etc. The idea was that businesses would pay extra for a certificate that guaranteed they were the legitimate brand. However, users couldn't easily differentiate between these levels, so there was no point.

Now people have come to realize a cert basically ties a service to a domain name and that is basically the best you can do in most cases.

ClumsyPilot2• 1 year ago

The idea was that businesses would pay extra for a certificate that guaranteed they were the legitimate brand

I really liked that functionality, it made sense to me

udev4096• 1 year ago

CAs should have been a thing of past by now. We should learn from the truly distrusted architecture of Tor onion services. There is no central authority in onion services, the site owner has full control over the site. All the traffic is always encrypted and you don't have to trust anyone for it

WhyNotHugo• 1 year ago

We could also be relying on DNSSEC+DANE, where the domain owner publishes TLS public keys via DNS. Without a third party CA.

The main limitation right now is browser support. Browsers _only_ support CAs, so CAs continue being the norm.

mycall• 1 year ago

Brave should try an implementation as it fits their paradigm.

growse• 1 year ago

Who do you think signs the DNSSEC root?

dadrian6• 1 year ago

The main limitation is the incredibly opaque and brittle nature of putting keys in DNS.

We've spent a decade and a half slowly making the Web PKI more agile and more transparent by reducing key lifetimes, expanding automation support, and integrating certificate transparency.

None of that exists for DNS, largely by design.

Spivak3• 1 year ago

You don't even need DNSSEC because CAs will happily issue you a cert without it.

cryptonector6• 1 year ago

Note that DNSSEC is a PKI, but it's fantastically better than a WebPKI because a) you get a single root CA, b) you can run your own private root CA (by running your own `.`), c) if clients did QName miniminzation then the CAs wouldn't easily know when it's interesting to try to MITM you. Oh, and DNS has name constraints naturally built-in while PKIX only has them as an extension that no one implements.

The only real downsides are that DNSSEC doesn't have CT yet (that'd be nice), this adds latency, and larger DNS messages can be annoying.

jeroenhd2• 1 year ago

Outside of some European TLDs, DNSSEC is pretty much unused. Amazon's cloud DNS service only recently started supporting it and various companies trying to turn it on ran into bugs in Amazon's implementation and got painful downtime. Hell, there are even incompetent TLDs that have DNSSEC broken entirely with no plan for fixing it any time soon.

Another problem with DNSSEC is that the root is controlled by the United States. If we start relying on DNSSEC, America gains the power to knock out entire TLDs by breaking the signature configuration. Recent credible threats of invading friendly countries should make even America's allies fearful for extending digital infrastructure in a way that gives them any more power.

immibis• 1 year ago

Your registrar would be able to MITM your website - and prevent you from noticing, since there's no Certificate Transparency in this case.

lxgr11• 1 year ago

You have to trust whoever you got an Onion link from, and yourself to not fall for a similar-looking one, since it is the trusted private key.

It's a web-of-trust and/or TOFU model if you look at it closely. These have different tradeoffs from the PKI, but don't somehow magically solve the hard problems of trusted key discovery.

Spivak3• 1 year ago

Sure but the web is already TOFU even with CAs because the only thing being asserted is that your connected to someone who (probably) controls the domain.

The client is perfectly able to verify that when connecting without a central authority by querying a well-known DNS entry. Literally do what the CA does to check but JIT.

This does leave you vulnerable to a malicious DNS server but this isn't an impossible hurdle without re-inventing CAs. With major companies rolling out DoH all you care about is that your DNS server isn't lying to you. With nothing other than dnsmasq you can be your own trusted authority no 3rd party required.

dooglius• 1 year ago

You also have to trust where you get a non-onion link from?

some_random• 1 year ago

TOR did not in fact magically solve all trust, you have to (potentially blindly) trust that the URL you've been given or you've found is who it says it is. It's not uncommon for scammers to change URLs on directories from real businesses or successful scams to their scam and there's no way to detect this if it's your first time.

dadrian6• 1 year ago

The Tor service model is equivalent to if every site used a self-signed certificate, which doesn't scale.

The more feasible CA-free architecture is to have the browser operator perform domain validation and counter-sign every sites key, but that has other downsides and is arguably even less distributed.

jeroenhd2• 1 year ago

The Tor system does scale, as Tor itself proves. Tor just lacks domain names all together and reuses public keys for site identification instead.

Is the tor node you're accessing the real Facebook or just a phishing page intercepting your credentials? Better check if the 60 character domain name matches the one your friend told you about!

I don't think putting any more power in browser vendors is the right move. I'd rather see a DNSSEC overhaul to make DANE work.

cryptonector6• 1 year ago

This is nonsense. The introduction problem can't just go away, and trust meshes, PKIs, and other schemes are all not panaceas.

Why on Earth would I trust some "site owner" (who are they? how do I authenticate them?) to operate an "onion service" securely and without abusing me? Do you not have a circular reasoning problem here?

All the traffic is always encrypted and you don't have to trust anyone for it

Sure you do! You have to trust the other end, but since this is onion routing you have to trust many ends.

1oooqooq• 1 year ago

One issue I have is governments that serve their own CA which you must trust before accessing their services. BR, IN, CN, RU, some US federal services (which might still exist after musk junta took over), ES, etc...

I'm fine with some gov bureaucrat setting the keys for their own services, but the CAs are usually able to sign for all the internet. Would be nice if browsers/OS would allow an easy way to limit the TLDs you accept to trust a CA, but that is on the cert.

BizarroLand• 1 year ago

Is there a reliable way to, for instance, distrust all FB/Meta certs in my homelab so that any service that attempts to contact them would fail?

How to distrust a CA without any certificate errors

Related Stories