Note: If your application does not absolutely need it, there are alternatives to X.509 certificates in TLS, like raw public keys (RFC 7250).
Added to OpenSSL last November: https://www.openssl.org/blog/blog/2023/11/23/OpenSSL32/index...
We build X.509 chains so you don't have to
41–50 of 88 posts
Re: We build X.509 chains so you don't have to
#42Aren't revocations a pretty important part of certificates, considering the whole point of this is security? I don't understand the rationale for skipping.
Re: We build X.509 chains so you don't have to
#43Earlier quoted context omitted.
This reasoning doesn't make sense. I didn't say it didn't help at all, I said I wouldn't expect it to make a significant improvement over Java (and it's hardly the strongest type system with "developer ergonomics")
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 would be a massive massive improvement
Re: We build X.509 chains so you don't have to
#44Aren'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.
Re: We build X.509 chains so you don't have to
#45Aren't revocations a pretty important part of certificates, considering the whole point of this is security? I don't understand the rationale for skipping.
[deleted]
Re: We build X.509 chains so you don't have to
#46> Carcinize existing C and C++ X.509 users. This could be game-changing for a lot of open source software. I spent years avoiding X.509 (and ASN.1, for that matter) in my designs because every time someone I trust poked it, a remotely exploitable bug fell out. Most often, it was a Denial of Service issue rather than Remote Code Execution. Moving to Rust would demonstrably improve the security of the entire Internet.…
> Moving to Rust would ... ... do absolutely nothing to fix denial of service attacks.
Exploiting a memory safety crash, leading to a downed service, is the first class of DOS that Rust can help with.
Re: We build X.509 chains so you don't have to
#47Earlier quoted context omitted.
Do you think that it's possible to implement a good path building algorithm without support for revocation? For example, without revocation checking you may select a chain with a revoked certificate in it, only to discover that later. Then what? :) On the other hand, if you check the revocation status as part of the process, you can pivot to another certificate.
I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism. What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path…
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 just fine, it's just that browsers decided not to implement it.
Re: We build X.509 chains so you don't have to
#48Earlier quoted context omitted.
> Is it really “Python” if the underlying stuff is written in another language? Given that "python" is basically synonymous with "cpython" and cpython has always been implemented in C, I guess the answer to your question is "yes".
A language is distinct from its implementation language. Else everything is machine code.
I never argued otherwise. But how is using a package which is implemented in another language not "python"? How is "list(range(10))" python whereas "numpy.arange(10)" is not?
Re: We build X.509 chains so you don't have to
#49Earlier quoted context omitted.
I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism. What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path…
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.
Re: We build X.509 chains so you don't have to
#50Earlier quoted context omitted.
I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism. What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path…
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 problems with X.509 PKIs is that you can make them fractally complex; every implementation ends up setting its own "I give up, doing this is too painful" point. CRLs are a common "give up" point, and that probably won't change until CRLite or similar changes things here.
(AIA chasing and OCSP lookups are also similar pain points.)