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

71–80 of 88 posts

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

#71

Post by ivanr »

woodruffw wrote: post #70
ivanr wrote: post #67

Earlier quoted context omitted.

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…

Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to indicate that it's only valid with an attached—stapled—fresh OCSP response) solves that.

When must-staple initially came out, it came to light that web servers viewed OCSP stapling as a performance optimisation. When viewed from this perspective, it's not necessary to staple 100% correctly; if you don't, clients just go to the CA directly. Unfortunately, this breaks apart with must-staple and clients who refuse to talk to Cash for privacy reasons.

Browsers refused to enforce must-staple because that would mean broken web sites and they didn't want to be blamed for it. As a result, web servers didn't have an incentive to fix their broken OCSP stapling implementations.

There's also some politics involved. Browsers don't actually want CAs to be able to revoke certificates for reasons other than security. Think one government pressuring a CA in their country to revoke a certificate of an entity outside the country, for political reasons.

(EDIT I don't really support this argument. Any organisation that cares about their availability should always have two active certificates from difference CAs. There's a variety of CA jurisdictions to choose from as well.)

I don't like these long discussion chains as much as the next guy, but there's a lot of nuance and history when it comes to certificate revocation, and I sometimes take the opportunity to gently question people's beliefs. The line "revocation doesn't work" is very often repeated and technically it's not wrong, but I think it's important for people to understand how we got here.

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

#72

Post by mcpherrinm »

ivanr wrote: post #49
mcpherrinm wrote: post #40

Earlier quoted context omitted.

I recently gave a talk on this topic (sorry, haven't written as a blog post yet) https://www.youtube.com/watch?v=4TbtL73ibh0 I do believe revocation in the webpki is important to implement, but it's not great today. There are two promising paths forward, which are complementary: The simple option is short-lived certificates (7 days), which essentially don't require revocation as that's the timeline existing revocatio…

There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.

Google's CRLSets don't cover nearly the full set of revocations (AFAIK).

I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar.

I mostly cite CRLite as it's well-documented.

I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn't seem to be happening. I think it is stuck in a spiral of non-adoption, where there's no incentive for anyone to make progress. I believe short-lived certs (7 days) are more deployable in the ecosystem today than ocsp must-staple, with similar security properties. Certificate automation is already desirable, and it's not as big a leap once flows are automated.

This isn't going to happen overnight at least. Years, probably many. But it's happening.

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

#73

Post by tptacek »

mcpherrinm wrote: post #72
ivanr wrote: post #49

Earlier quoted context omitted.

There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.

Google's CRLSets don't cover nearly the full set of revocations (AFAIK). I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar. I mostly cite CRLite as it's well-documented. I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn'…

"The spiral of non-adoption" is an interesting blog post someone should write. I bet there are a couple more examples besides the obvious one.

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

#74

Post by ivanr »

mcpherrinm wrote: post #72
ivanr wrote: post #49

Earlier quoted context omitted.

There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.

Google's CRLSets don't cover nearly the full set of revocations (AFAIK). I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar. I mostly cite CRLite as it's well-documented. I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn'…

I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :)

OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right).

Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction.

Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.

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

#75

Post by e12e »

ivanr wrote: post #74
mcpherrinm wrote: post #72

Earlier quoted context omitted.

Google's CRLSets don't cover nearly the full set of revocations (AFAIK). I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar. I mostly cite CRLite as it's well-documented. I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn'…

I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on becaus…

As far as I can figure out, most ocsp staples are valid for 7 days, so short lived certificates would be equivalent, but simpler?

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

#76

Post by nindalf »

blibble wrote: post #43
k8svet wrote: post #38

Earlier quoted context omitted.

I'm not even that good at writing Rust and even I recognize that countless libs I'm using are written in a way, with Rust types, that prevent serious mis-use. In ways that would be infeasible and unergonomic in other languages, or require internal library invariant assertions that are prone to bugs. Sometimes the errors wind up being nasty, but I've also gotten better at trusting that the compiler is giving me helpfu…

yes, hence my comment on SML while it's nice that the rest of the world is slowly waking up to type systems functional programmers have been bleating on about for the past four decades ... having read through the first couple of pages of bc vulns: even a much stronger type system than rust provides wouldn't appear to help very much in this specific example however if someone wants to rewrite OpenSSL in Rust that woul…

> however if someone wants to rewrite OpenSSL in Rust

You mean rustls?

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

#77

Post by ivanr »

e12e wrote: post #75
ivanr wrote: post #74

Earlier quoted context omitted.

I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on becaus…

As far as I can figure out, most ocsp staples are valid for 7 days, so short lived certificates would be equivalent, but simpler?

Indeed, you're right. Must-staple and short-lived certificates have the same problem with clock skew.

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

#78

Post by ivanr »

woodruffw wrote: post #69
ivanr wrote: post #66

Earlier quoted context omitted.

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 .

You may also want to look at https://github.com/digicert/pkilint

There are other similar tools (cablint, x509lint, zlint), but there's been a lot of good talk about pkilint recently.

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

#79

Post by im3w1l »

I'm sure it was even worse before, but I'm not entirely happy with the look of that.

* I shouldn't have to care where the certificates are stored. Just load the os default ones without asking me.

* I shouldn't have to know what a pem is, and I shouldn't have to open() one.

* I don't want a PolicyBuilder. Just give me the normal policy.

* I shouldn't have to construct some verifier object specific to a given dns. I don't want to verify a billion certificates for one domain, just one.

* I shouldn't have to know what an untrusted intermediary is.

Here's what I think it should look like

  verifier = Verifier()  # constructs a verifier with sensible defaults, overrides are possible though
  verifier.verify(chain, "cryptography.io")

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

#80

Post by nindalf »

dang wrote: post #68
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…

Holy fucking shit. I've never seen anything like that last comment on HN before.
Post reply on HN