Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Certificate Authority root stores have a too simple view of 'trust'

utcc.utoronto.ca

Post reply on HN
Print view View original

21–30 of 120 posts

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#21

Post by mananaysiempre »

est31 wrote: post #8

There are definitely limitations in GNU/Linux root stores. E.g. to my knowledge it's impossible to distinguish between the root coming from the distro vs coming from a custom configuration, e.g. for corporate MITM proxies. So you can't e.g. require SCTs to be present for former but not require them for latter, like how Chrome does it for example. Also, is this additional information even published by Mozilla in a sta…

> is this additional information even published by Mozilla in a standardized format or if it's just put somewhere into Firefox source code?

Not really a single format, but they do write it down:

https://wiki.mozilla.org/CA/Additional_Trust_Changes

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#22

Post by mike_hearn »

e12e wrote: post #18
ayende wrote: post #2

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example. But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that. And I can do that in multiple different TLS engines. Given that there is no API for…

> There is no API to actually handle trust. We might need something more - but I wonder i trust-stores could be modified so that: - every device get a "host" CA (like a ssh key) - this CA is the only one trusted - in turn, this CA signs issuer/top-level CA (or even cross-signs the intermediary certs directly) (eg with - new/-force_pubkey) Additional logic could be applied in the signing step - say rules to set the va…

Certificates advertise if they're meant to be roots or not and libraries enforce that via things like the path length constraints, so it wouldn't work. But it also just seems kind of complicated - how is that any easier than just updating the root store in a cron job, which is already done via normal package maintenance routines anyway?

The reason the Linux root stores don't have a notion of 'trust until' like the article wants is simple - nothing stops an untrusted CA just issuing certificates that claim to have been issued before the cutoff, so it seems pointless. Browsers have ways to tackle that like Certificate Transparency or crawling the web to try and identify every extant cert, but most apps don't use that.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#23

Post by pifm_guy »

Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed.

So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates.

If you don't trust the CA to act honestly for now, then you need to remove them from the trust store entirely (and maybe use a whitelist of previously issued certificates if you believe they were trustworthy in the past).

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#24

Post by tinus_hn »

ayende wrote: post #2

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example. But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that. And I can do that in multiple different TLS engines. Given that there is no API for…

There’s a surprising amount of old Unix software like Postfix, that by default doesn’t actually validate certificates.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#25

Post by dontbenebby »

ayende wrote: post #2

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example. But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that. And I can do that in multiple different TLS engines. Given that there is no API for…

If you reflect on trusting trust too long, you’ll drive yourself mad.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#26

Post by nsajko »

jamespwilliams wrote: post #5

Even when Mozilla does fully remove stuff from their root store, in some cases it has taken distros a year+ to ship the updated version Not to mention stuff like this: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+b... , where Ubuntu just unilaterally reverted Mozilla’s removal of a cert in their package, because it was breaking nuget… Note that this was early 2021 — Mozilla removed Symantec from their t…

Isn't that just Ubuntu being idiotic as usual?

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#27

Post by koolba »

pifm_guy wrote: post #23

Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed. So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates. If you don't trust the CA to act honestly for now, then you need to remove them from the trust…

> Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed.

Dare I say it, but isn't this the exact problem solved by a chain of published certificate hashes?

This is pretty much how certificate transparency lists (CTL) work too. It's like a blockchain without any proof of work or stake, just a merkle tree of hashes that ensures you cannot retroactively insert one with an older date.

> ... (and maybe use a whitelist of previously issued certificates if you believe they were trustworthy in the past).

Which I guess would be only trusting CTL published certificates up until the last point of trust.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#28

Post by jamespwilliams »

pifm_guy wrote: post #23

Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed. So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates. If you don't trust the CA to act honestly for now, then you need to remove them from the trust…

See https://news.ycombinator.com/item?id=33877290

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#29

Post by cbzoiav »

pifm_guy wrote: post #23

Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed. So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates. If you don't trust the CA to act honestly for now, then you need to remove them from the trust…

Trust isn't black and white. Removing the cert entirely breaks existing applications which comes with its own risk.

Using TrustCor as an example there is no hard evidence they have done anything wrong. Is that enough to justify cutting off their clients?

What if one of those clients is a major antivirus vendor etc. with pinned certs in their software? Or road signs etc.?

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#30

Post by gjvc »

tinus_hn wrote: post #24
ayende wrote: post #2

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example. But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that. And I can do that in multiple different TLS engines. Given that there is no API for…

There’s a surprising amount of old Unix software like Postfix, that by default doesn’t actually validate certificates.

Postfix is not old. Sendmail is old :-)
Post reply on HN