jaas

6 ms·

31.
by jaas 1y ago
Let’s Encrypt has already started issuing a limited number of 6-day certs and they will be generally available later this year. (90 days will remain the default though)
32.
How we reduced the impact of zombie clients(letsencrypt.org)
184 points by jaas 1y ago|39 comments
33.
by jaas 1y ago
The repository is here: https://github.com/rustls/rustls-openssl-compat We just work with normal issues/PRs, and there is a Rustls discord channel if you want to chat. We'd love your help!
34.
by jaas 1y ago
Rustls uses aws-lc-rs for cryptography, which, roughly speaking, is based on the cryptography from BoringSSL, which is a heavily modified fork of OpenSSL from a long time ago. I'm not sure how similar OpenSSL and aws-lc-rs cryptography
35.
by jaas 1y ago
I think what you're quoting says what I was saying - assembly with some C around it, wrapped in a Rust API. At least for the "select" (read: most important) algorithms. The details of the C/asm boundary in aws-lc are har
36.
by jaas 1y ago
In Rustls, DER, and all certificate parsing and validation in general, is done in Rust. https://github.com/rustls/webpki
37.
by jaas 1y ago
In Rustls, TLS is implemented entirely in Rust. It uses aws-lc-rs [1] for cryptography, and aws-lc-rs uses assembly for core cryptographic routines, which are wrapped in some C code, which then exposes a Rust API which Rustls uses. It'
38.
by jaas 1y ago
This report contains more details about the results discussed in the blog post: https://rustls.dev/perf/2024-11-28-threading/
39.
by jaas 1y ago
I'm the person who is running the rav1d bounty, also involved with the Rustls project. In many (most?) situations I think Rust is effectively as fast as C, but it's not a given. They're close enough that depending on the situ
40.
by jaas 1y ago
Rustls has two C APIs. The first is C bindings for the native Rustls API. This should work great for anyone who wants to use Rustls from C, but it means writing to the Rustls API. The second is C bindings that provide OpenSSL compatibility.
41.
by jaas 1y ago
The default cryptographic back-end for Rustls, aws-lc-rs, is FIPS compliant and integrated in a FIPS-compliant way so it's easy to get FIPS compliance with Rustls.
42.
by jaas 1y ago
This is the correct answer (we run this bounty). Contests can be legally complex, there are only so many place we feel comfortable running it from a legal POV.
43.
Rustls Server-Side Performance(memorysafety.org)
171 points by jaas 1y ago|60 comments
44.
by jaas 1y ago
> We also tested Rustls and its rustls-openssl-compat layer. Rustls could be an interesting library in the future, but the OpenSSL compatibility application binary interface (ABI) was not complete enough to make it work correctly with HA
45.
by jaas 1y ago
I don't think an additional standard library layer, whatever you call it, has to have the same tight controls on backwards compatibility and evolution that the actual standard library has. IMO the goal of creating it should be to impro
46.
by jaas 2y ago
We consider our ten year anniversary to be in 2025 but I appreciate the kind words here! Today is roughly the ten year anniversary of when we publicly announced our intention to launch Let's Encrypt, but next year is the ten year anniv
47.
Rustls Outperforms OpenSSL and BoringSSL(memorysafety.org)
154 points by jaas 2y ago|44 comments
48.
by jaas 2y ago
No team is going to prevent issues like this 100% of the time. That's a wildly unrealistic expectation. Wherever the bar is, it won't be 100%. That's why good leadership invests in the ability to respond well to mistakes that
49.
by jaas 2y ago
Yes, I disagree. Best case scenario I think it would just allow us to get rid of the CDN layer. We'd still have to build and manage the rest with utmost care. Even that really depends on what the "SLA" expectation is. How man
50.
by jaas 2y ago
OCSP systems at scale are complex. At the core there is an on-demand or pre-signed OCSP response generation system, then there is usually an internal caching layer (redis or similar), then there is an external CDN layer. Just because the ou
51.
by jaas 2y ago
People bring up postfix all the time in this context because supposedly nobody has ever found a memory safety vulnerability in it. Presumably this is supposed to make the point that it is possible to write complex programs in C safely. The
52.
by jaas 2y ago
ntpd-rs support NTS, I agree it would be great if more people used it!
53.
by jaas 2y ago
I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply
54.
Rustls Gains OpenSSL and Nginx Compatibility(memorysafety.org)
4 points by jaas 2y ago|0 comments
55.
by jaas 3y ago
I assume you're asking why the underlying crypto still needs to be written in asm. There are two primary reasons: 1. Performance 2. Defense against side channel attacks (e.g. constant time operations)
56.
by jaas 3y ago
The Rustls TLS implementation and certificate verification are all safe Rust. The underlying cryptography is still a mix of C and asm, that's the best option we have now particularly if we want support for things that make it deployabl
57.
River: A Reverse Proxy Built on Pingora(memorysafety.org)
29 points by jaas 3y ago|3 comments
58.
by jaas 3y ago
Because thieves know that all iPhones are locked like this and thus don’t steal them. If they knew that some significant percentage were not locked they would be worth stealing again, and if it’s locked they just throw it in a dumpster. The
59.
by jaas 3y ago
This did not cost us $225k. About half that. Nobody pays the website price, you pay a lot less via a VAR. - ED of ISRG / Let's Encrypt
60.
by jaas 3y ago
Those numbers are misleading. IdenTrust has always been a small CA in terms of volume. The large percentage you see for them there is actually Let's Encrypt volume counted as IdenTrust because of the cross-sign. The Let's Encrypt

More ›