We build X.509 chains so you don't have to
blog.trailofbits.com
We build X.509 chains so you don't have to
1–10 of 88 posts
Re: We build X.509 chains so you don't have to
#2Congratulations 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
Re: We build X.509 chains so you don't have to
#3[flagged]
Re: We build X.509 chains so you don't have to
#4Do we have this in PHP? Javascript ?
Re: We build X.509 chains so you don't have to
#5I'm curious -- what was the inputs to the decision to redo the logic from scratch, rather than wrap something like the `webpki` crate?
Re: We build X.509 chains so you don't have to
#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.
You might be tempted to ask, "What about BouncyCastle?" (or similar queries).
Sure, you're not overwriting the EIP in most Java X.509 bugs, but check the release notes for X.509 and ASN.1 mentions: https://www.bouncycastle.org/releasenotes.html
When I worked for Amazon, we disclosed a few X.509-related vulnerabilities to projects that we almost found by accident.
Re: We build X.509 chains so you don't have to
#7Do we have this in PHP? Javascript ?
I think getting it into cURL would be more impactful, since that's already tapped into by many OSS projects.
Re: We build X.509 chains so you don't have to
#8Fantastic!
Curious about revocations though - the post doesn't mention it?
Re: We build X.509 chains so you don't have to
#9[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
Re: We build X.509 chains so you don't have to
#10I'm curious -- what was the inputs to the decision to redo the logic from scratch, rather than wrap something like the `webpki` crate?
This is a great question! The answer is twofold:
1. Compatibility: PyCA Cryptography has strict compatibility requirements, including being able to build with older versions of Rust that crates like webpki and rustls-webpki may not be interested in supporting.
2. Generality: PyCA Cryptography is a general purpose cryptographic toolbox, and the plan for X.509 validation is not intrinsically linked to just the Web PKI profiles. In the future, they may wish to make their APIs more flexible than a strictly CABF validator would require, meaning that they would either need to carry patches against `webpki` or get such flexibility upstreamed (to the detriment of the crate's single purpose).
(I am not a maintainer of Cryptography; this is my understanding of the reasons as one of the implementors of this feature.)