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

We build X.509 chains so you don't have to

blog.trailofbits.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: We build X.509 chains so you don't have to

#51

Post by ivanr »

woodruffw wrote: post #44
flumpcakes wrote: post #42

Aren't revocations a pretty important part of certificates, considering the whole point of this is security? I don't understand the rationale for skipping.

Revocations are a great idea. In practice, they're both operationally complicated and an unreliable source of truth about certificate validity. In practice, a lot of implementations (including Go's) simply ignore them. 'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful. [1]: https://news.ycom…

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

Re: We build X.509 chains so you don't have to

#52

Post by ivanr »

woodruffw wrote: post #50
ivanr wrote: post #47

Earlier quoted context omitted.

Exactly. Because you currently don't check for revocation, you may end up selecting a path that's a dead end and you won't be able to recover. However, if your implementation has pluggable [dynamic] constraints, once you add support for revocation, it will work optimally. You can run into the same problem with any other constraint, for example hash function deprecation, CA block, and so on. Aside: Revocation works ju…

I don't think pluggability is the important thing here: a good path building implementation doesn't need to be pluggable to handle dynamic constraints correctly. More precisely: a "dead path" is only a problem if it somehow excludes otherwise present valid paths, which is not an issue if you chose to not support CRLs at all (you might accept revoked paths, but you certainly won't exclude non-revoked ones). One of the…

Well, yes. If you choose to ignore revocation entirely, you will never have a dead path because of it. That will happen only if you path-build, then check revocation as two steps. (IIRC, Windows used to do this, or is still doing it.)

IMO, a good path building implementation has to support revocation, but that's for another conversation :)

Re: We build X.509 chains so you don't have to

#54

Post by woodruffw »

ivanr wrote: post #51
woodruffw wrote: post #44

Earlier quoted context omitted.

Revocations are a great idea. In practice, they're both operationally complicated and an unreliable source of truth about certificate validity. In practice, a lot of implementations (including Go's) simply ignore them. 'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful. [1]: https://news.ycom…

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

I'm thinking about CRL update windows: a lot of CAs run weekly updates, meaning that CRL changes don't propagate to end users for up to a week at a time. That's well into "security theater" territory for me, given that a compromised CA or EE only needs to fool me for a matter of seconds, once.

Re: We build X.509 chains so you don't have to

#55

Post by ak217 »

ivanr wrote: post #51
woodruffw wrote: post #44

Earlier quoted context omitted.

Revocations are a great idea. In practice, they're both operationally complicated and an unreliable source of truth about certificate validity. In practice, a lot of implementations (including Go's) simply ignore them. 'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful. [1]: https://news.ycom…

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

[Not OP]

CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale.

You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr..., https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...

Revocation in PKI is a hard problem that exposes a fundamental tradeoff between time to revoke and privacy/offline capability.

Re: We build X.509 chains so you don't have to

#56

Post by ivanr »

ak217 wrote: post #55
ivanr wrote: post #51

Earlier quoted context omitted.

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

[Not OP] CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale. You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr... , https://en.wikipedia.org/wiki/Online_Certificat…

Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.

Re: We build X.509 chains so you don't have to

#57

Post by ivanr »

woodruffw wrote: post #54
ivanr wrote: post #51

Earlier quoted context omitted.

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

I'm thinking about CRL update windows: a lot of CAs run weekly updates, meaning that CRL changes don't propagate to end users for up to a week at a time. That's well into "security theater" territory for me, given that a compromised CA or EE only needs to fool me for a matter of seconds, once.

Sure, but then you can just use OCSP. If you care about privacy very much, support only stapled OCSP.

CRL is better suited for "high-volume" exchanges, for example for a CA to publish all their revocations [so that a system such as CRLite can be built].

Re: We build X.509 chains so you don't have to

#58

Post by ak217 »

ivanr wrote: post #56
ak217 wrote: post #55

Earlier quoted context omitted.

[Not OP] CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale. You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr... , https://en.wikipedia.org/wiki/Online_Certificat…

Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.

PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints).

There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.

Re: We build X.509 chains so you don't have to

#59

Post by ivanr »

thadt wrote: post #20

While the contribution to Python Cryptography is incredibly awesome, I'd suggest that perhaps the lede is slightly buried. Having a large suite of well documented test vectors, including both positive and negative examples, raises the bar for the entire ecosystem. Go and OpenSSL are mentioned, but any other environment implementing X.509 now has another very well developed test suite that can be plugged in directly.…

Agreed. I don't see NIST's test suites [1] on the list, though. Maybe they're embedded somewhere and I've missed it?

[1] https://csrc.nist.gov/projects/pki-testing

EDIT If the authors are reading, are any of the test cases taken from Chrome's codebase?

Re: We build X.509 chains so you don't have to

#60

Post by ivanr »

ak217 wrote: post #58
ivanr wrote: post #56

Earlier quoted context omitted.

Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.

PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints). There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.

That's a fair point [PKI without TLS], but I'd argue that 99.9% of situations will be with TLS. Thus supporting revocation can provide value for those.

Out of curiosity, what without-TLS use cases do you have in mind?

Post reply on HN