3 ms·

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 ho

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

mlindner 5y ago
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.
- agency 5y ago
  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 https://github.com/aws/s2n-tls
  - tialaramex 5y ago
    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.
    - colmmacc 5y 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.
      - tialaramex 5y ago
        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?
        colmmacc 5y ago
        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.
  - capableweb 5y ago
    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.
- eptcyka 5y ago
  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.
- capableweb 5y ago
  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.

mlindner 5y ago

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.

agency 5y ago
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 https://github.com/aws/s2n-tls
- tialaramex 5y ago
  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.
  - colmmacc 5y 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.
    - tialaramex 5y ago
      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?
      - colmmacc 5y ago
        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.
- capableweb 5y ago
  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.
eptcyka 5y ago
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.
capableweb 5y ago
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.