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

31–40 of 88 posts

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

#31

Post by woodruffw »

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

The "classic" example of this is enums as sum types, rather than a thin wrapper over an integral type: Rust makes it possible to construct in invalid enum variant, whereas plenty of C logic bugs stem from taking untrusted user input and converting it into an enum variant.

My understanding is that Java doesn't allow this directly, but has adjacent historical deficiencies (e.g., not allowing exhaustive enumeration handling until recently).

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

#32

Post by blibble »

tob_scott_a wrote: post #30
blibble wrote: post #24

Earlier quoted context omitted.

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.

I think that attitude vastly underestimates the complexity of a typical TLS implementation

(and I say this as someone who grew up on SML)

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

#33

Post by woodruffw »

blibble wrote: post #32
tob_scott_a wrote: post #30

Earlier quoted context omitted.

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.

I think that attitude vastly underestimates the complexity of a typical TLS implementation (and I say this as someone who grew up on SML)

This reasoning doesn't make sense. If TLS is astonishingly complex, which it is, then we absolutely want the strongest type system that can simultaneously represent its complexity and afford developer ergonomics. TLS's complexity is a good reason for types that reflect invariants, not a good reason to give up.

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

#34

Post by tob_scott_a »

blibble wrote: post #32
tob_scott_a wrote: post #30

Earlier quoted context omitted.

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.

I think that attitude vastly underestimates the complexity of a typical TLS implementation (and I say this as someone who grew up on SML)

> I think that attitude vastly underestimates the complexity of a typical TLS implementation

If you ever get the impression that I'm underestimating the complexity of a typical TLS implementation, I promise you that I'm not. I speak to improvements, not panaceas.

Until the end of last year, I was one of the security engineers that the s2n team at AWS consulted on potential security issues. You will never hear me say anything will magically fix all our problems. Especially with TLS.

However, Rust does bring a lot to the table, so I feel I'm allowed to be excited about not reviewing another X.509 library written in C.

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

#35

Post by blibble »

woodruffw wrote: post #33
blibble wrote: post #32

Earlier quoted context omitted.

I think that attitude vastly underestimates the complexity of a typical TLS implementation (and I say this as someone who grew up on SML)

This reasoning doesn't make sense. If TLS is astonishingly complex, which it is, then we absolutely want the strongest type system that can simultaneously represent its complexity and afford developer ergonomics. TLS's complexity is a good reason for types that reflect invariants, not a good reason to give up.

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")

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

#37

Post by asylteltine »

efitz wrote: post #9
asylteltine wrote: post #3

[flagged]

Yes. Python was designed from the beginning to be compatible with C; it can make calls directly into C modules. There is an entire portion of the Python ecosystem dedicated to C interoperability. Many of the most popular packages are written in C (e.g. numpy, pandas, etc.) and many other packages have the most performance-sensitive code written in C (scipy et. al.) [ed] s/pansas/pandas/g

[flagged]

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

#38

Post by k8svet »

blibble wrote: post #35
woodruffw wrote: post #33

Earlier quoted context omitted.

This reasoning doesn't make sense. If TLS is astonishingly complex, which it is, then we absolutely want the strongest type system that can simultaneously represent its complexity and afford developer ergonomics. TLS's complexity is a good reason for types that reflect invariants, not a good reason to give up.

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 helpful info, even if it's a huge message. And usually those errors indicate some library invariant that I've missed that the type system is enforcing.

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

#39

Post by notaluddite »

Given the ambiguities and degrees of freedom different TLS clients can exercise during chain validation (mentioned in this post), we wrote a paper proposing that validation policies should be expressed as interchangeable Prolog programs: https://dl.acm.org/doi/pdf/10.1145/3548606.3560594

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

#40

Post by mcpherrinm »

woodruffw wrote: post #23
ivanr wrote: post #22

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

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 revocation technology can revoke on, but that has some adoption hurdles to overcome in the future.

The other solution is what Mozilla is doing with CRLite: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

They are collecting all CRLs from all public web CAs and producing a small, compressed representation of all revoked certificates. That can be pushed to clients, so there's no need for any network traffic (like OCSP checks or CRL downloads) to the wide variety of CAs in the ecosystem.

These "CRL Compact and Push" solutions benefit from shorter-lived certificates (eg, 90 days like Let's Encrypt does right now) because the set of revoked certs is smaller as they roll off once they expire.

I suspect platform verifiers like on Windows and Mac will hopefully ship something like this in the future, though they already have CRL and OCSP fetching and caching.

Non-platform verifiers like this one are really the hardest part to solve revocation. I would suggest supporting CRL checks, but that requires having disk space and caching infrastructure, which is hard for a library to know how to do universally. I think the answer is that we need to have most of our software outsource to a platform verifier, or at least some sort of system-wide revocation information cache or daemon. Maybe this means a new systemd component on Linux :)

Post reply on HN