S2n-QUIC (Rust implementation of QUIC) | Hacker News Reader

S2n-QUIC (Rust implementation of QUIC)

github.com

105 pointsjeffbarr24 comments

I wonder how they compare (but I'm not willing to spend hours comparing for myself).

I do note in passing that S2n-QUIC has a really nice set of examples of how to use right up front in the README. All libraries should ideally have that. Without reading anything else, I already have a good idea of how hard it would be to use S2n-QUIC (looks easy).

BTW I will note that almost all Rust crypto (including that used by both packages) is all based on the ring crate, which is rather problematically managed and is itself a bunch of assembly and C code that's just taken straight from BoringSSL and OpenSSL.

It looks like by default s2n-quic uses this TLS implementation, which is not based on the ring crate (though it is written in C)

https://github.com/aws/s2n-tls

However, that TLS implementation still thinks accepting TLS 1.0 is not only a reasonable default but also something you won't ever want to switch off except via an "I know what I'm doing" setting, and their "default" configuration has rusted into place several years ago.

I think we're getting closer to TLS1.0 disabled by default, but there are still clients out there and that's all they do. Especially embedded systems. It's a good practice to turn off old protocols but it has to be balanced with system availability. We go pretty deep on TLS and pay a lot of attention to what the problems in each protocol version are and having mitigations for them. A big source of comfort too is that it's been a long time since new clients can be made to fallback to old versions when they shouldn't.

You're coming up on a year after RFC 8996 (saying to stop using TLS 1.0), which is itself almost three years after the die-die-die draft and RFC 8446 (TLS 1.3)

I get why s2n has an SSLv3 implementation, even if it SSLv3 was already a bad idea by the time s2n existed, and I would likewise understand why it still has TLS 1.0, but I don't understand how it makes sense to advertise a "default" strategy that enables TLS 1.0 but not TLS 1.3 in 2022.

If as I assumed in my earlier comment "default" is rusted in place as meaning "The thing that happened to work when this was popularised and now we dare not change it" then I guess that's a sad way for s2n's team to learn about Hyrum's Law but you should just stop advertising the "default" feature having learned that lesson, continuing to have docs that say "Use the defaults" when the defaults are rusted in place is bad.

Or maybe I just don't understand and s2n is only intended for some niche legacy scenarios where TLS 1.3 won't make sense?

One of my original goals from the very beginning of s2n was to move decisions like which protocols to support, which ciphers to prioritize and so on out of the hands of system administrators and compliance auditors and into the hands of experts who go deep on the protocols and the trade-offs involved. I'd seen just far too many Apache and Nginx configs with non-sensical cipher configuration streams. On top of that goal we also layer the principal of making decisions that are driven by hard data, wherever possible, and not just fashions.

We've changed the defaults in the past, in response to issues that we think are fatal blows, it's not about ossifying the default we happened to start with. It's simply that we know that right now if we disabled TLS1.0/1.1 by default; it would break some customers and users and we have a high bar to clear for that. At this point, only old clients who can do no better even negotiate TLS1.0/1.1. More modern clients can not be downgraded to TLS1.0/1.1 as long as they support the now well-deployed anti-fallback features that are in TLS. For those old clients that do use TLS1.0/1.1, the issues that are present in those protocol versions are not practically exploitable. The MD5_SHA1 handshake signature is probably the closest to exploitable and it is still not practical to compute those signatures within the handshake timeout windows. Other issues, like the lack of explicit IVs in 1.0 are mitigated with 1/n-1 record splitting (at least in one direction), and so on. Of course those old clients should upgrade and use TLS1.2! I just think there is a high bar for making them via brinkmanship, many of the clients left are things like BluRay players and TVs that shipped firmwares without an ability to do over the air updates. It'd just break things like video streaming and leave consumers figuring out how to flash-update an ancient device. I don't think it's good stewardship to force people through that.

Now that some compliance requirements like FedRAMP/FIPS and PCI are starting to require TLS1.0/1.1 disabled, I do think we owe a simpler way to disable them for that reason. I do wish standards like that took a more deep and specific consideration of the risks involved. As for TLS1.3, we've been running and using it and contributed to its development and support for it is there, but we're still detecting clients that don't handle TLS1.3 correctly and have been working with them (and adding workarounds on our side). We have the benefit of a lot of data for all of these decisions, and we really want things to work reliably for people. Our customers tell us that's most important.

> Now that some compliance requirements like FedRAMP/FIPS and PCI are starting to require TLS1.0/1.1 disabled

PCI required people to stop using TLS 1.0 in 2018 which I know feels like maybe last week but it was actually four years ago.

If Security really is #1 then "TLS Session Resumption is now actually safe" (in TLS 1.3) feels like a big win, while "This BluRay player can't connect to my brand new service" feels like a comparatively tiny loss. How recent do you reckon the trust store is inside that BluRay player? Five, ten, 15 years old?

Running `cargo tree | grep -i ring` shows ring v0.16.20 a whopping 7 times in the s2n-quic repository, so it's somewhere alright.

That's because currently it's impossible to ensure that rustc won't short-circuit a function if it sees an opportunity to do so, which means it's impossible to write constant-time functions which is a necessity for any kind of production ready crypto code.

Keyword being almost all. I ran `cargo tree | grep -i ring` in all four currently listed QUIC implementations, and three of them have ring somewhere in the dependency tree, except for mozilla/neqo.

Also: https://github.com/cloudflare/quiche CloudFlare's QUIC implementation written in Rust

Also: https://github.com/mozilla/neqo - Neqo, an Implementation of QUIC written in Rust

Is there a "can I use" for networks/middleboxes/etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC universally?

I'd love to use QUIC between a (non-browser) client and server for which both ends are code I've written, without having to have fallbacks to HTTP/1.1 or HTTP/2. (Among other things, I love the idea of just establishing one connection and using it for two-way communication, without worrying about things like WebSocket.)

However, the client also needs to run in random places, and while it doesn't necessarily need to support hostile networks, it does need to support broken networks, which to a first approximation can be similar.

Are there statistics available for whether and how often QUIC (or more generally UDP) works with:

- Random ISPs of varying quality - Cell data connections - Shops and airports and similar, which commonly use captive portals and try to intercept traffic when they shouldn't, and come pretty close to being hostile networks - Vaguely reasonable corporate networks, that aren't trying to block QUIC but might do so through misconfiguration or through some misguided policy put in place for unrelated reasons (e.g "our firewall rules are written about TCP and just drop all UDP and ICMP, and people complain but nobody with the power to change it") - Somewhat less reasonable corporate networks, that force everything through a proxy and may require things like CONNECT-UDP or SOCKS, but still aren't actively trying to block QUIC

I'm hoping that efforts like fly.io's userspace wireguard stack (which uses UDP) might have data here.

I'm specifically not asking about the case of networks that are actually trying to be hostile (to QUIC or otherwise), both because such networks may break any number of things including TLS or WebSockets, and because I'd like to avoid restarting the recurring discussion about whether QUIC/etc are a conspiracy to disempower network administrators. I'd love to know the statistics there too, though, if they're available.

I'm also curious about the best-known method to reliably and efficiently tunnel QUIC out of a network within a client, for the purposes of separating always-QUIC logic from weird-network-handling logic. Does it make sense, for instance, to have a standard way to tunnel a secure QUIC connection through an insecure TCP connection?

i think tunnelling quic over TCP might run into the same problems you have when tunnelling TCP/IP over TCP. if you have two congestion algorithms running then you get weird performance issues.

http://sites.inka.de/~W1011/devel/tcp-tcp.html

Absolutely. But if it's only needed on a small fraction of networks, it might still be worth doing in order to write code that can otherwise assume QUIC.

if you control the client/server in these situations in might be worth just using HTTP/2 instead of QUIC for these networks. just write your protocol assuming 'streams' exist and then have a HTTP/2 and a QUIC implementation. this is what cloudflare does with their cloudflared tunnel.

The are statistics. But those are mostly available for teams which are currently running quic in production at large scale and see the success and fallback rates. Roughly it works for > 90% of users, and you might be able to add more 9s depending on the region.

Buts as you said the details are tricky, because there’s many reasons for it to fail. Network ACLs where either UDP is totally blocked or certain ports (like 443) are the obvious ones. But we’ve also experienced other issues where eg VPN setups didn’t support the minimum required MTU size for Quic.

The recommendation to deal with situation where it does not work are the fallbacks you mentioned. For HTTP, both clients and servers are still expected to support lower versions for both interoperability and reliability.

For other use cases creating plain TCP/TLS connections can be a fallback - even if it’s one per stream. Or running one of them and another multiplexing layer like yamux on top. I wouldn’t recommend tunneling quic over tcp or things alike - this might end up in flow control and congestion control mechanisms fighting having bad interactions and leading to poor performance. Quic assumes an unreliable datagram based transmission layer, and having a reliable layer below it will mean retransmission of data which is no longer required by the quic layer.

there's a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features!

> and much more, including CUBIC congestion controller support, packet pacing, Generic Segmentation Offload support, Path MTU discovery, and unique connection identifiers detached from the address

also, a blog announcement appeared for this, https://aws.amazon.com/blogs/security/introducing-s2n-quic-o...

I wonder why ye olde CUBIC without offering a choice of BBR or - dare I dream it - Swift.

Is Swift (https://dl.acm.org/doi/pdf/10.1145/3387514.3406591) expected/designed to be used in non-intra dc environments where primarily quic is expected to have an advantage relative to tcp?

I agree that it still would be nice to have as an option.

Well I don’t really agree with the premise of your statement. I think that the benefit of the new protocol is going to mostly be felt inside the data center.

CUBIC is a good baseline congestion controller. It's the default one that is being used in Linux, so it should provide adequate performance for a wide range of use-cases. Plus it's not so "olde" - the specification is actively improved (see https://github.com/NTAP/rfc8312bis), and the implementation of the algorithm inside s2n-quic even lead to the discovery of spec gaps that had been fixed as part of this effort.

Like most other QUIC libraries the congestion controller is also pluggable. So if a different one makes more sense for a particular use-case, it could be integrated in the future.

Reply on news.ycombinator.com