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

21–30 of 88 posts

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

#21

Post by otabdeveloper4 »

tob_scott_a wrote: post #6

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

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

#22

Post by ivanr »

woodruffw wrote: post #11
e12e wrote: post #8

Fantastic! Curious about revocations though - the post doesn't mention it?

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

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.

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

#23

Post by woodruffw »

ivanr wrote: post #22
woodruffw wrote: post #11

Earlier quoted context omitted.

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

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 building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations).

[1]: https://medium.com/@sleevi_/path-building-vs-path-verifying-...

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

#24

Post by blibble »

tob_scott_a wrote: post #6

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

how would rust fix most of those issues?

they're logic bugs

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

#25

Post by caeruleus »

reaperhulk wrote: post #16
caeruleus wrote: post #2

Congratulations to the authors, this was a feature that was dearly missing from pyca/cryptography. It took a long time to get right. For the history: https://github.com/pyca/cryptography/issues/2381

Thanks for posting! I had forgotten just how long a road this was, but I'm very pleased that the requirements we talked about years ago have been met. :) That's not to say this is done! There's a set of features we still want to add and we'd like to gain some confidence in the APIs as structured before we mark them as stabilized.

Looking forward! Thanks for maintaining such an awesome library btw, most of my internal PKI (X.509 and OpenSSH) is managed with it. It's a bliss to work with, even more so compared to other crypto libs. :)

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

#26

Post by tob_scott_a »

otabdeveloper4 wrote: post #21
tob_scott_a wrote: post #6

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

By itself? No.

The other details covered in the blog post, however, would absolutely do something to fix denial of service attacks.

To wit: x509-limbo

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

#27

Post by Zambyte »

CogitoCogito wrote: post #15
asylteltine wrote: post #3

[flagged]

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

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

#28

Post by woodruffw »

otabdeveloper4 wrote: post #21
tob_scott_a wrote: post #6

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

I don't think this is true. Rust cannot prevent all possible forms of denial of service, but there are plenty of underlying DoS causes that Rust either outright eliminates (such as memory corruption without further control) or mitigates through stronger types.

A recent example of this is CVE-2024-0567 in GnuTLS: an invariant that otherwise would likely have been noticed at the type level is instead checked with an assert, leading to a remotely trigger-able DoS.

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

#29

Post by saurik »

otabdeveloper4 wrote: post #21
tob_scott_a wrote: post #6

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

Nor the other myriad of logic and parsing bugs that led to incorrect behavior (more than just denial of service) in the Java library that was somehow not as good as Rust :/.

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

#30

Post by tob_scott_a »

blibble wrote: post #24
tob_scott_a wrote: post #6

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

how would rust fix most of those issues? they're logic bugs

woodruffw already wrote an excellent comment for this question: https://news.ycombinator.com/item?id=39131723

Rust isn't just memory-safety. The type system also coaxes developers towards eliminating some types of logic bugs.

Not all, granted, but it does move the needle.

Post reply on HN