4 ms·

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 go

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.
  - tialaramex 5y ago
    > 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?

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.
- tialaramex 5y ago
  > 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?