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

11–20 of 120 posts

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

#11

Post by daveoc64 »

AceJohnny2 wrote: post #9
jannic wrote: post #7

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. How does this work? If TrustCor is no longer trusted, what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

Certificate Transparency [1]: Public logs of issued certificates. [1] https://en.wikipedia.org/wiki/Certificate_Transparency

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

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

#12

Post by pimterry »

jannic wrote: post #7

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. How does this work? If TrustCor is no longer trusted, what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

> what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

See https://groups.google.com/a/mozilla.org/g/dev-security-polic... for the actions proposed depending on how the TrustCor situation plays out:

> If there is reason to believe that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity certificates to expire.

Right now, they're being slowly removed for poor behaviour in general, but there's no direct evidence of abuse of CA powers. If any clear evidence of that appears in future, including backdating certificates, then they'll be completely removed from the trust store immediately.

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

#13

Post by pimterry »

daveoc64 wrote: post #11
AceJohnny2 wrote: post #9

Earlier quoted context omitted.

Certificate Transparency [1]: Public logs of issued certificates. [1] https://en.wikipedia.org/wiki/Certificate_Transparency

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.

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

#14

Post by kelnos »

deathanatos wrote: post #4
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…

Yeah, TFA seems to make a good argument for a libca-certificates, or so. > There is another aspect, as well. You need to be able to express those issues as errors, otherwise the user is going to be left with a broken box and no idea what is going on. TLS libraries are terrible at this. Part of it is C: the "integer is the only error type you'll ever need" cannot convey the necessary context, such as which cert is the…

> TLS libraries are terrible at this. Part of it is C: the "integer is the only error type you'll ever need" cannot convey the necessary context, such as which cert is the problem.

Not really; I mean, sure, the validation function will probably rely on returning an integer error code, but there's no reason that the API couldn't also provide a function to retrieve the certificate chain at hand, where an application could walk the chain backwards to the root and figure out the last one (er, or first one, depending on how you look at it) that isn't trusted.

Whether an application would choose to go to the trouble to make use of these APIs is another matter, of course. At any rate, from perspective of the average user, TLS errors are already not so easy to understand, so giving detailed information in this case might not be all that helpful anyway. Just a simple "we don't trust this website, so you shouldn't either" is about as much as most users would understand, probably.

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

#15

Post by est31 »

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.

Firefox doesn't: https://bugzilla.mozilla.org/show_bug.cgi?id=1281469

(But it's the only browser that doesn't support CT)

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

#16

Post by blibble »

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…

> 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 :(

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

#18

Post by e12e »

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 validity, or rules to sign/not-sign. One might set a 48h lifetime, and run a crown job every night - allowing for "dynamic" "revocation" (cert expiry).

Not sure if this would work out of the box though - I have not looked that deep into ca and ca trust.

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

#19

Post by ayende »

kelnos wrote: post #14
deathanatos wrote: post #4

Earlier quoted context omitted.

Yeah, TFA seems to make a good argument for a libca-certificates, or so. > There is another aspect, as well. You need to be able to express those issues as errors, otherwise the user is going to be left with a broken box and no idea what is going on. TLS libraries are terrible at this. Part of it is C: the "integer is the only error type you'll ever need" cannot convey the necessary context, such as which cert is the…

> TLS libraries are terrible at this. Part of it is C: the "integer is the only error type you'll ever need" cannot convey the necessary context, such as which cert is the problem. Not really; I mean, sure, the validation function will probably rely on returning an integer error code, but there's no reason that the API couldn't also provide a function to retrieve the certificate chain at hand, where an application co…

That assumes that the application even know to check the "only valid if issued before" flag.

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

#20

Post by mike_hearn »

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 uses those formats too.

Java actually solves the complaint in this thread, and has done for a long time. The JDK has its own root store program run by Sun and now Oracle, TLS APIs use the bundled root store automatically, it provides tools to manage that root store, exceptions are easily rendered to users in a generic way, and it provides a mix of high and low level APIs.

What you're probably thinking of is the JKS format. Java defined a way to represent a root store on disk that's Java specific, I think because there was no standard at the time. But it migrated to the PKCS#12 format in recent releases.

Post reply on HN