3 ms·

> If the implementation is "modern" why would I allow 1.0 ? Because there's a distinction between "using" (especially by default) and "implementing". The real

> If the implementation is "modern" why would I allow 1.0 ? Because there's a distinction between "using" (especially by default) and "implementing". The real world has millions (billions?) of devices that don't receive updates and yet still need to be talked to, in most cases luckily by a small set of communication partners. Would you rather have even the "modern" side of that conversation be forced to use some ancient SSL library? I'd rather have modern software, even if I'm forced to use an older protocol version by the other endpoint. Just disable it by default. And it's not like TLS 1.0 and 1.1 are somehow worse than cleartext communication. They're still encrypted transport protocols that take significant effort to break. That you shouldn't use them if at all possible doesn't mean that you can't use them if anything else is impossible.

tialaramex 1y ago
> And it's not like TLS 1.0 and 1.1 are somehow worse than cleartext communication. In reality humans can't actually do this nuance you're imagining, and so what happens is you're asked "is this secure?" and you say "Yes" meaning "Well it's not cleartext" and then it gets ripped wide open. HTTP in particular is like a dream protocol for cryptanalysis. If in 1990 you told researchers to imagine a protocol where clients will execute arbitrary numbers of requests to any server under somebody else's control (Javascript) and where values you control are concatenated with secrets you want to steal (Cookies) they'd say that's nice for writing examples, but nobody would deploy such an amateur design in the real world. They would be dead wrong. But eh, we wrote an RFC telling you not to use these long obsolete protocol versions, and you're going to do it anyway, so, whatever.
- eqvinox 1y ago
  > In reality humans can't actually do this nuance […] Luckily the cases that need this aren't normally about a wide user base, rather they only concern a bunch of developers and admins. Which is why I pointed out the default-off nature of this. > But eh, we wrote an RFC telling you not to use these long obsolete protocol versions, and you're going to do it anyway, so, whatever. You're losing audience with unnecessary hostility. Your post would've been much more effective with plain omitting this last paragraph.
jeroenhd 1y ago
Exposing TLS 1.0 leaves your connections vulnerable to BEAST. Requiring TLS 1.2 deprecates clients older than what, Android 4.4.2 and Safari 9? Maybe exceptional cases like IoT crapware and fifteen year old smart phones you might still need 1.1? I don't see why you'd want to take on the additional work and risk otherwise. In practice TLS 1.2 has been available for long enough that it should be the bare minimum at this point. If I were to implement a TLS server today, I'd start at 1.2, and not bother with anything older. All of the edge cases, ciphers, protocols, config files, and regression tests are wasted time and effort.
- citrin_ru 1y ago
  BEAST is AFIR mitigated by RC4. It is vulnerable too but an attack on RC4 requires significant traffic never sent by many clients. Everything is a tradeoff and denying service to old clients sometimes worse than to introduce a small risk of TLS not being able to stop MitM.
- eqvinox 1y ago
  > Exposing TLS 1.0 leaves your connections vulnerable to BEAST. So? > Requiring TLS 1.2 deprecates clients older than what, Android 4.4.2 and Safari 9? Maybe exceptional cases like IoT crapware and fifteen year old smart phones you might still need 1.1? You're underestimating the amount of "IoT crapware" out there. And industrial control systems. And other early internet-ified infrastructure. Even bringing up Android and Safari hints that you're not thinking in the same direction I am. I'm concerned about RTEMS, FreeRTOS, Zephyr, and oooooold versions of mbedTLS or wolfSSL. These systems were built using "stable" versions. What do you think was stable 10-15 years ago? That's 20 year old software. I'm happy if it's TLS and not SSL, my dear friend.

tialaramex 1y ago

> And it's not like TLS 1.0 and 1.1 are somehow worse than cleartext communication. In reality humans can't actually do this nuance you're imagining, and so what happens is you're asked "is this secure?" and you say "Yes" meaning "Well it's not cleartext" and then it gets ripped wide open. HTTP in particular is like a dream protocol for cryptanalysis. If in 1990 you told researchers to imagine a protocol where clients will execute arbitrary numbers of requests to any server under somebody else's control (Javascript) and where values you control are concatenated with secrets you want to steal (Cookies) they'd say that's nice for writing examples, but nobody would deploy such an amateur design in the real world. They would be dead wrong. But eh, we wrote an RFC telling you not to use these long obsolete protocol versions, and you're going to do it anyway, so, whatever.

eqvinox 1y ago
> In reality humans can't actually do this nuance […] Luckily the cases that need this aren't normally about a wide user base, rather they only concern a bunch of developers and admins. Which is why I pointed out the default-off nature of this. > But eh, we wrote an RFC telling you not to use these long obsolete protocol versions, and you're going to do it anyway, so, whatever. You're losing audience with unnecessary hostility. Your post would've been much more effective with plain omitting this last paragraph.

jeroenhd 1y ago

Exposing TLS 1.0 leaves your connections vulnerable to BEAST. Requiring TLS 1.2 deprecates clients older than what, Android 4.4.2 and Safari 9? Maybe exceptional cases like IoT crapware and fifteen year old smart phones you might still need 1.1? I don't see why you'd want to take on the additional work and risk otherwise. In practice TLS 1.2 has been available for long enough that it should be the bare minimum at this point. If I were to implement a TLS server today, I'd start at 1.2, and not bother with anything older. All of the edge cases, ciphers, protocols, config files, and regression tests are wasted time and effort.

citrin_ru 1y ago
BEAST is AFIR mitigated by RC4. It is vulnerable too but an attack on RC4 requires significant traffic never sent by many clients. Everything is a tradeoff and denying service to old clients sometimes worse than to introduce a small risk of TLS not being able to stop MitM.
eqvinox 1y ago
> Exposing TLS 1.0 leaves your connections vulnerable to BEAST. So? > Requiring TLS 1.2 deprecates clients older than what, Android 4.4.2 and Safari 9? Maybe exceptional cases like IoT crapware and fifteen year old smart phones you might still need 1.1? You're underestimating the amount of "IoT crapware" out there. And industrial control systems. And other early internet-ified infrastructure. Even bringing up Android and Safari hints that you're not thinking in the same direction I am. I'm concerned about RTEMS, FreeRTOS, Zephyr, and oooooold versions of mbedTLS or wolfSSL. These systems were built using "stable" versions. What do you think was stable 10-15 years ago? That's 20 year old software. I'm happy if it's TLS and not SSL, my dear friend.