Linux Certificate Authority root stores have a too simple view of 'trust' • Hacker News Board

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

#61

Post by mdeslaur » Tue, Dec 06, 2022, 2:11 PM UTC

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… Note that this was early 2021 — Mozilla removed Symantec from their trust store in October 2018!

Mozilla actually removed the certs from their trust store in February 2021: https://hg.mozilla.org/projects/nss/rev/9718a34c84429b1e5dc6...

Debian and Ubuntu had jumped the gun by a few weeks and there were certificates still being used that had not been renewed yet, so we had to revert temporarily.

Mozilla had used the CKA_NSS_SERVER_DISTRUST_AFTER tag with a date to specify newer certs issued by that CA were not valid, but as the article above states, the crypto libraries being used in Linux don't support that kind of thing.

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

#62

Post by mdeslaur » Tue, Dec 06, 2022, 2:12 PM UTC

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.

> Ubuntu has never seemed to take security particularly seriously.

I haven't heard that before. Care to elaborate what we do that makes you believe we don't take security seriously?

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

#63

Post by yrro » Tue, Dec 06, 2022, 2:15 PM UTC

ilyt wrote: post #40

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

Every TLS library will also have to implement it.

I hate to say it but... I want a systemd-certd that TLS libraries can call into saying 'verify this please' and then the logic for verifying trust path, validity, revocation status etc can be done in one place, consistently and correctly.

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

#64

Post by mdeslaur » Tue, Dec 06, 2022, 2:18 PM UTC

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"

Oh no, our terrible secret is out! :)

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

#65

Post by DethNinja » Tue, Dec 06, 2022, 2:21 PM UTC

pimterry wrote: post #13

daveoc64 wrote: post #11

Earlier quoted context omitted.

Assuming the untrusted and unreliable CA actually follows the rules and publishes things to the CT log.

If you don't then the certificates usually aren't usable at all. All modern browsers should reject certs from any root CA if the cert isn't correctly included in a CT log.

Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.

Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions.

Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the moment.

Certificate system is actually rather insecure, and although solutions are possible to develop, nobody has taken time to do it.

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

#66

Post by bioemerl » Tue, Dec 06, 2022, 2:22 PM UTC

I hate the concept of certificate authorities in general. I wish we had a way to do robust security without them.

The idea that you need the approval of one of these companies to publish to the web without a wall of alerts is just absurd.

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

#67

Post by jamespwilliams » Tue, Dec 06, 2022, 2:25 PM UTC

mdeslaur wrote: post #61

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… Note that this was early 2021 — Mozilla removed Symantec from their trust store in October 2018! Mozilla actually removed the certs from their trust store in February 2021: https://hg.mozilla.org/projects/nss/rev/9718a34c84429b1e5dc6... Debian and Ubuntu had jumped the gun by a few weeks and there we…

My mistake, I misread “Removal/distrust” in the timeline of https://wiki.mozilla.org/CA/Symantec_Issues as meaning removal from the trust store.

I can’t edit my comment now, but hopefully your correction here gets upvoted and is visible to people.

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

#68

Post by Ajedi32 » Tue, Dec 06, 2022, 2:32 PM UTC

ak217 wrote: post #60

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…

> 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.

AFAIK those are standards for allowing CAs to revoke certificates. Trust conditions for root stores are a completely different thing.

Or at least, I'm certainly not aware of any mechanism in the CRL standard to "partially revoke" a CA certificate based on complex conditions like "What's the notBefore date on the leaf certificate we're currently validating?".

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

#69

Post by [deleted] » Tue, Dec 06, 2022, 2:39 PM UTC

mdeslaur wrote: post #62

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.

> Ubuntu has never seemed to take security particularly seriously. I haven't heard that before. Care to elaborate what we do that makes you believe we don't take security seriously?

[deleted]

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

#70

Post by Fatnino » Tue, Dec 06, 2022, 2:57 PM UTC

NovemberWhiskey wrote: post #46

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.

> So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them. Did TrustCor turn out to have done that? The last time I checked in on that, the distrust was mainly founded on some not-very-trustworthy behavior involving spyware in a related company within the same corporate umbrella. EDIT: Link to the rationale for distrust from Mozilla ... https://groups.google.com/a/mozilla.…

To be removed, a CA just needs to show it is not worthy of trust.

TrustCor met this requirement and got removed.

Other CAs removed in the past also showed they are unworthy of trust, but in even more blatant ways.