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

31–40 of 120 posts

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

#31

Post by bawolff »

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…

You can trust a CA to be honest but not competent. In which case an orderly transition makes sense

After all, backdating certs is really obvious in a world with cert transpatency, and you can full distrust immediately if they do that.

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

#32

Post by cesarb »

blibble wrote: post #16
kelnos wrote: post #10

Earlier quoted context omitted.

> There is no API to actually handle trust. The various TLS libraries already agree on at least one thing: what certificates look like on disk (e.g. PEM and DER formats). There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here. Then the TLS libraries would have to implement it, and return appropriate errors from their validation…

> The various TLS libraries already agree on at least one thing: what certificates look like on disk (e.g. PEM and DER formats). Java would like a word with you :(

Java has always been its own separate world. For instance, recently we had daylight saving issues on a server (we no longer have daylight savings time, but the Java application thought it had just started). The server did have an updated timezone database with the correct rules... but Java uses a separate timezone database, which hadn't been updated.

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

#33

Post by cmeacham98 »

koolba wrote: post #27
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 r…

You're not describing a blockchain here, but rather a Merkle tree (also called a hash tree). Or, (because the tree-like behavior is actually undesirable here) just an array of hashes.

Just because something has a set of hashes in a roughly linear timeline doesn't make it a blockchain. For example, git isn't a blockchain either.

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

#34

Post by dark-star »

Yesterday I have removed that certificate from all my Linux systems. So far I have not seen any impact in connectivity for any applications or websites I use.

And even if, all I'd get is a "this site is not trusted" that I can manually override if required.

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

#35

Post by cmeacham98 »

nsajko wrote: post #26
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?

Ubuntu has never seemed to take security particularly seriously.

So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.

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

#37

Post by xg15 »

mike_hearn wrote: post #22
e12e wrote: post #18

Earlier quoted context omitted.

> 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 ar…

Linux root stores could piggyback on the browsers' efforts here though. The attack scenario you described was sensible in the past, so it didn't make sense for non-browser clients to go ahead with "trust until".

However, now CAs can't really do this anymore, because - as you say - they'd risk immediate exclusion from browsers if this is detected via CT analysis. So Linux distros can actually benefit from CT and browser's impact in the CA space in an indirect manner.

There is definitely a power imbalance though. E.g., even if a distro implemented "trust until", they could not realistically make their own rules that are stricter than what browsers do: CAs could backdate certs so they get accepted by the distro, but if browsers consider the CA fully trusted, they might not care about the backdated certificates.

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

#38

Post by wbl »

cbzoiav wrote: post #29
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.?

Clients? They only had one client for web certs ever, a dynamic DNS service.

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

#39

Post by ilyt »

cmeacham98 wrote: post #35
nsajko wrote: post #26

Earlier quoted context omitted.

Isn't that just Ubuntu being idiotic as usual?

Ubuntu has never seemed to take security particularly seriously. So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.

The more I see it the more I think Ubuntu's "job" is "take a sensible Debian distribution and just fucking break shit in it"

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

#40

Post by ilyt »

By "Linux" it really means any SSL lib that just uses system's "a dir with a bunch of CAs" approach.

That approach is nice for ops (don't have to worry about commands to add/remove certs, just drop files into dir) and relatively performant (just one read on cert's fingerprint file name in modern distros).

I think simplest one would be just adding meta file with a bunch of conditions ?

While we're at it, allow the certs to be imported only for certain domain, so ops can, for example, import internal CA of their partner but limit it to only partner's domains

Post reply on HN