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

51–60 of 120 posts

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

#51

Post by rlpb »

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…

> ...where Ubuntu just unilaterally reverted Mozilla’s removal of a cert in their package, because it was breaking nuget

It wasn't unilateral. Ubuntu followed Debian here, who did the same revert: https://tracker.debian.org/media/packages/c/ca-certificates/...

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

#52

Post by zenexer »

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?

Interestingly, this time around, Ubuntu actually removed TrustCor from its root store almost immediately. That technically means that some certificates that should still be valid are now invalid on Ubuntu.

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

#53

Post by actionfromafar »

jeltz wrote: post #44
no_time wrote: post #42

Earlier quoted context omitted.

Their strong point has always been design and branding. I love their fonts and a few years ago they were the only ones with a patched libfreetype that didn't make your eyes bleed. As for engineering decisions, let's just say better stick with debian on anything non-desktop.

The only issue with Debian is if you want the latest version of some application, e.g. Firefox then installing it is far from a nice experience. And Debian testing is quite unstable (I run it on my laptop so I know). Love it for my servers but it is not very convenient for the desktop.

I wish Debian would release 20.04 LTS, 22.04 LTS and so on.

That is the big feature of Ubuntu for me. Can set in my calendar when it's time to migrate services to the next version.

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

#54

Post by jefftk »

ilyt wrote: post #39
cmeacham98 wrote: post #35

Earlier quoted context omitted.

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"

That may or may not be the case, but this incident is not evidence for it, since Debian did the same thing. See upthread: https://news.ycombinator.com/item?id=33879202

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

#55

Post by pferde »

jeltz wrote: post #44
no_time wrote: post #42

Earlier quoted context omitted.

Their strong point has always been design and branding. I love their fonts and a few years ago they were the only ones with a patched libfreetype that didn't make your eyes bleed. As for engineering decisions, let's just say better stick with debian on anything non-desktop.

The only issue with Debian is if you want the latest version of some application, e.g. Firefox then installing it is far from a nice experience. And Debian testing is quite unstable (I run it on my laptop so I know). Love it for my servers but it is not very convenient for the desktop.

I have been running Debian Stable on my (gaming/coding/general use) desktop and on my work laptop for close to a decade now, and I have had very few problems, things just work. The last problem of "too old system libraries" nature I remember was maybe 5 years ago, when Steam client did not work because of too old glibc, but one Debian release later the problem was gone.

I don't think it's as bad as most people think it is, nowadays.

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

#57

Post by usr1106 »

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.

When I renewed my Let's Encrypt certifcate the last time I noticed that my postfix was still using the certificate that had expired 3 months later. I don't receive a whole lot of email on that machine, but I did not notice any delivey failures.

I started to think (but not check specs): Is it even defined what domain name should be checked? MX records can be different from server names. Maybe certificate checking is just not defined for SMTP over TLS?

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

#59

Post by usr1106 »

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…

It was not said at all why that CA lost Mozilla's trust. If their key were leaked of course backdated certificates could be produced at any time.

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

#60

Post by ak217 »

kelnos wrote: post #10
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. 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…

> 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

They already have (https://www.rfc-editor.org/rfc/rfc5280.html, https://www.rfc-editor.org/rfc/rfc6960.html) but CRL/OCSP functionality not implemented in most libraries because it's hard and thankless work.

Post reply on HN