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

61–70 of 88 posts

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

#61

Post by ak217 »

ivanr wrote: post #60
ak217 wrote: post #58

Earlier quoted context omitted.

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?

Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS.

Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit.

There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures.

And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.

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

#62

Post by woodruffw »

ivanr wrote: post #59
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?

(I'm one of the authors).

I looked at NIST's PKITS while building the test suite. We ultimately decided to punt on it for the first round of tests, primarily because it fell slightly out of scope of our MVP on Python Cryptography (being strictly a RFC 3280 suite). We instead chose to integrate the BetterTLS suite[1] (warning: very large page) for the MVP.

With that being said: x509-limbo is open source, and I would be overjoyed if someone added a new `nist::pkits` or similar namespace for these :-). I can't promise that it's an immediate priority for us to add ourselves, however.

> are any of the test cases taken from Chrome's codebase?

Nope. That would also be a valuable thing to have here.

[1]: https://x509-limbo.com/testcases/bettertls/

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

#63

Post by baby »

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

Check Frankencerts as well if you're interested in that: https://github.com/sumanj/frankencert

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

#65

Post by woodruffw »

ivanr wrote: post #57
woodruffw wrote: post #54

Earlier quoted context omitted.

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

The comment I referenced before contains a talk by 'mcpherrim as well that explains OCSP stapling's own deficiencies.

I think we all want a good solution here. But none of the currently widely deployed ones are that.

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

#66

Post by ivanr »

woodruffw wrote: post #62
ivanr wrote: post #59

Earlier quoted context omitted.

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?

(I'm one of the authors). I looked at NIST's PKITS while building the test suite. We ultimately decided to punt on it for the first round of tests, primarily because it fell slightly out of scope of our MVP on Python Cryptography (being strictly a RFC 3280 suite). We instead chose to integrate the BetterTLS suite[1] (warning: very large page) for the MVP. With that being said: x509-limbo is open source, and I would b…

For reference: https://github.com/chromium/chromium/tree/main/net/data/ssl

It's been a long time since I looked at them, not sure what's in there exactly any more. Ask Ryan perhaps :)

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

#67

Post by ivanr »

woodruffw wrote: post #65
ivanr wrote: post #57

Earlier quoted context omitted.

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

The comment I referenced before contains a talk by 'mcpherrim as well that explains OCSP stapling's own deficiencies. I think we all want a good solution here. But none of the currently widely deployed ones are that.

I am sorry, I can't watch someone else's talk to understand what you mean. If you're willing to engage in a conversation, could you say here what you think the problems with OCSP are? (If you're not, just ignore me.)

As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today maybe even those are fixed. The main problem IMO is that browsers won't support must-staple.

In the interest of full transparency, I have a pet peeve about people saying revocation doesn't work. I appreciate that that's the current reality, but—again—only because browsers choose not to implement it. Things would change overnight if Chrome (obviously) changed their stance.

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

#68

Post by dang »

asylteltine wrote: post #3

[flagged]

We've asked you more than once to stop posting unsubstantive comments and flamebait. You've continued to do it, for example in the parent comment, https://news.ycombinator.com/item?id=39108095, and https://news.ycombinator.com/item?id=39103476.

You've even posted outright slurs like https://news.ycombinator.com/item?id=38832516, which is seriously not ok.

Since you've continued to break HN's rules like this, I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.

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

#69

Post by woodruffw »

ivanr wrote: post #66
woodruffw wrote: post #62

Earlier quoted context omitted.

(I'm one of the authors). I looked at NIST's PKITS while building the test suite. We ultimately decided to punt on it for the first round of tests, primarily because it fell slightly out of scope of our MVP on Python Cryptography (being strictly a RFC 3280 suite). We instead chose to integrate the BetterTLS suite[1] (warning: very large page) for the MVP. With that being said: x509-limbo is open source, and I would b…

For reference: https://github.com/chromium/chromium/tree/main/net/data/ssl It's been a long time since I looked at them, not sure what's in there exactly any more. Ask Ryan perhaps :)

Thank you! I'll add that to https://github.com/C2SP/x509-limbo/issues/174.

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

#70

Post by woodruffw »

ivanr wrote: post #67
woodruffw wrote: post #65

Earlier quoted context omitted.

The comment I referenced before contains a talk by 'mcpherrim as well that explains OCSP stapling's own deficiencies. I think we all want a good solution here. But none of the currently widely deployed ones are that.

I am sorry, I can't watch someone else's talk to understand what you mean. If you're willing to engage in a conversation, could you say here what you think the problems with OCSP are? (If you're not, just ignore me.) As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today mayb…

Sure! I'm happy to discuss, my reason for referencing the video is because I think 'mcpherrim explains this stuff better than I do :-).

My understanding is that the primary concerns with OCSP (meaning non-stapled OCSP) are that it (1) leaks end user intent to CAs, such as sites being visited, and (2) in its original form with no transport security, it is no stronger than the adversary that it needs to protect TLS/the Web PKI against (i.e., any network adversary can block the OCSP request and everything will fail open).

OCSP stapling avoids both of those concerns, but requires web server and other stack changes that are not on the "enforcement" path in the way that CAs and other "direct" parts of the PKI are. The talk infers that this is why OCSP adoption has been so sluggish (which I didn't realize was the case before).

FWIW, I'm sorry if I came across as dogmatic here -- revocation is conceptually important, and I think it'd be great if we ended up in a Web PKI where revocation was more effective. But I can also see why browsers have fumbled and/or dragged their feet on the CRLs and OCSP for so long.

Post reply on HN