8 ms·

OpenSSL in Debian Unstable drops TLS 1.0/1.1 support

147 points by jhealy 9y ago

chickenbane 9y ago
Good. Debian won't be making stable any time soon, so a very reasonable timeline.
- pilif 9y ago
  I don’t know. We have customers connect to us with their internal systems they haven’t touched in ages. I can’t possibly tell them that they need to update their infrastructure two years (Debian has a two year release cycle and has released this year) from now. And then there are some end-users behind enterprise middle-boxes which don’t support anything beyond TLS 1.1 and I have a feeling it’s going to be difficult to communicate to them that they need to change the configuration. This means that we'll have to package our own FTP and HTTP servers in the future. Not a big deal, but certainly not something I'm looking forward to. Oh and our mail relay I probably have to build myself too or just disable TLS. You have no idea what shitty SSL configurations are used out there by the various systems trying to send us email. Grumble. At this point, I might as well run Linux from scratch when most of the daemons we run won't be able to talk to a seizable chunk of the clients connecting to us any more. In other words: if you set up Debian out of the box today, its default packages will talk to 99% of clients out there on the internet. If you set up Debian in 2019, about 30% of the clients out there won’t be able to talk to you. And the fix won’t just be a configuration change; it will require you to manually build every single daemon you make use of.
  - throwaway2048 9y ago
    I think introducing some friction here is a good idea, pre 1.2 tls/ssl are objectively broken, insecure protocols. Unless some of these people experience some pain and fix their shit, they will never upgrade, and by extension keeping everyone that wishes to communicate with them vulnerable as well (due to BAD_GUY being able to force protocol downgrades) Is it the right solution to accommodate them (not to mention by default out of the box which means it hurts your users without them being aware of it or able to make an informed choice) and pretend it isn't a problem, and thus putting yourself at risk too? For the same reasons i think its highly irresponsible people like FreeBSD patch in garbage like null cipher support into ssh. It is broken let the people who have to use it for whatever weird reason deal with the burden of their broken shit, don't force it on everyone else and weaken their security.
    - pilif 9y ago
      > not to mention by default out of the box sure. Disable it by default, but leave it compiled in, so an admin can re-enable it by changing a config setting instead of recompiling half a distro. > and thus putting yourself at risk too I'm not at risk if some big restaurant chain orders their supplies over TLS 1.1 instead of TLS 1.2. I'm not at risk if their email server sends us support tickets over TLS 1.1 instead of 1.2. However, my business is at risk if they can't order their supplies and if I then can't receive the support email telling me so. > patch in garbage like null cipher support into ssh there's a huge difference there: null-ciphers are completely pointless and no known client out there only supports null-ciphers. But about 30% of the internet doesn't support TLS 1.2.
      - throwaway2048 9y ago
        Its unfortunate that this situation causes you problems, but there is literally no other way that some people will ever upgrade their shit, you could wait 10 years and they will still be using tls1.1. Its important to at least make it harder than flip some switch and forget about it forever, or nothing is going to change.
        pilif 9y ago
        (Edit: this reply is a reply to a your comment before your edit that stated I was at risk because of non-mitigatable issues in 1.1) My 1.1 supporting customers are at risk. I'm not at risk. If they take the (unwise) decision that the risk of their connections being eavesdropped is less significant that the amount of work it takes to update their internal network, than its their decision. I am absolutely not in the position to do advocacy there. And neither are other companies who have to serve enterprise customers. „But allowing 1.1 will allow attackers to force secure 1.2 supporting clients to downgrade“ you might say. To which I reply: why are they still supporting 1.1? If they are security conscious enough to update their infrastructure to support 1.2, they can disable anything else when talking to me.
        madez 9y ago
  - bigbugbag 9y ago
    I am confused with your two years figure. With a two year release cycle in two years testing will become stable, but this change is in unstable which will become testing in two years. Or did I miss something here ?
    - 0x0 9y ago
      Packages in unstable can enter testing in 2-10 days, not years :) https://wiki.debian.org/DebianTesting https://wiki.debian.org/DebianTesting
      - jwilk 9y ago
        To be pedantically correct, the 2 days limit is incorrect. An upload with priority=emergency can be accepted to testing without extra delay.
  - pdw 9y ago
    Would it really be necessary to rebuild all daemons? It seems to me that it would be sufficient to drop in a custom libssl that doesn't disable the old protocols.
    - Conan_Kudo 9y ago
      Depends if the protocol change affects the API and ABI. I think with OpenSSL, it might. But I'm not sure about that...
  - rlpb 9y ago
    > At this point, I might as well run Linux from scratch... You might as well learn the Debian tooling and run a system with the OpenSSL package patched with a build-time change. On Ubuntu, that'd be the same as maintaining a PPA with one source package in it. On Debian, it's effectively the same except that you'll need reprepro or a script around apt-ftparchive instead. This is far easier than your hyperbole of running Linux from scratch.
  - Twirrim 9y ago
    At a previous job they finally deprecated RC4-MD5, long after almost everyone had stopped using it. About a week later they had to re-enable it, because it turned out a few major customers had some old SPARC (IIRC?) boxes that used the service. The extra overhead of non RC4-MD5 ciphers was crippling them. There was some seriously frantic back and forth with the customer to get the situation resolved and figure out a timeline to finally, finally, finally deprecate RC4-MD5.
  - yuhong 9y ago
    How many years do you estimate.
koolba 9y ago
Is there a plugin or setting for Firefox or Chrome that would give me stats on server protocol support for my own interactions? I'm pretty sure the preference is newer versions of TLS where available. So would be interesting to see if this would have any impact on ones own browsing habits (ignoring the fact that FF has its own TLS lib so wouldn't be using OpenSSL anyway).
- mholt 9y ago
  The inspector tools of both Firefox and Chrome will give you the protocol version and cipher suite selected.
  - sitkack 9y ago
    I am bummed that Chrome removed it from info tip over the lock icon. One has to dive into the developer tools tab to get this info now.
    - microcolonel 9y ago
      Yeah, it's really inconvenient and slow, I'd chime in if you want to file a bug report.
      - snailmailman 9y ago
        I mentioned in another comment but may as well put it here too. chrome://flags/#show-cert-link has a workaround that puts it back in a more easily accessible location in the dropdown from top left (where the site permissions currently are)
    - snailmailman 9y ago
      In the new chrome 60+, you can go to chrome://flags/#show-cert-link and then it can be found through a link under "view site information" again. just learned this the other day, a setting thats very well hidden.
      - 9y ago
rossy 9y ago
This makes me anxious, but I'm not sure if my anxiety is valid. I didn't know it was okay to disable TLS 1.0/1.1 this early. Correct me if I'm wrong, but this will affect all HTTPS web requests and web serving, as well as mail delivery and receipt from Debian sid. I'm not sure I want to only be able to surf ~90% of the encrypted web[1] and I'm not sure I'm ready to drop support for Android 4.3[2] or stock Windows 7/IE (which has TLS 1.2 switched off in Internet Options.) Not to mention all the mail servers out there running outdated crypto. I have mail in my inbox (from eg. Amazon Pay) received over TLS 1.0. As far as I understand, supporting outdated protocols like TLS 1.0 is only a problem if there is a downgrade attack that can force a server and client that speak TLS 1.2 to communicate over TLS 1.0. Otherwise, it should be fine to support TLS 1.0 to speak to older clients, while giving newer clients the option to speak over TLS 1.2. Hopefully this announcement is correct in the assumption that support for TLS 1.2 will be high enough when Buster is released. [1]: https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/ [2]: https://www.ssllabs.com/ssltest/clients.html https://www.ssllabs.com/ssltest/clients.html
- cft 9y ago
  Yes, you can't run a webserver on that Debian that supports tls with Android 4.3 or earlier for example.
  - pmlnr 9y ago
    I'm pretty certain you're being sarcastic, but on Debian, most of the users stick to the "stock", packaged ones, instead of building their own. Indeed you can build nginx with custom ssl, but most of the Debian users won't fiddle with this.
- vbernat 9y ago
  Browsing shouldn't be affected as it doesn't use OpenSSL. However, I share your concerns. The target is the next stable (two years), but many of us are running unstable or testing.
  - Conan_Kudo 9y ago
0x0 9y ago
Seems a little risky especially for SMTP services. Will be interesting to see how this pans out!
hannob 9y ago
I predict hereby that this change won't last long. While cryptographically it's the right move (everything below TLS 1.2 with an AEAD is cryptographically broken), this disables connectivity with half of the Internet. There is a huge number of hosts out there running on legacy hardware that won't do anything beyond TLS 1.0.
- bigbugbag 9y ago
  And those hosts ought to up their game or disappear. The other way to look at it is that you have security vulnerabilities because a portion of the internet is stuck in a decade old obsolete world.
  - r1ch 9y ago
    It's not just about hosts. In developing countries, old generation mobile phones running Android 4.x are extremely common. Google's own metrics show 26% of Android phones are pre-5.0, and that's without the unknown number that don't have Google Services installed. EDIT: Seems the last version of Android 4 does support TLS 1.2, but there's still a non-zero amount of users on older versions.
- codemusings 9y ago
  We're talking Debian Unstable. That change is at least 2 years out if you're running Testing on your servers or 4 years with Stable. I think that's a reasonable goal.
  - mmarx 9y ago
    > That change is at least 2 years out if you're running Testing on your servers or 4 years with Stable. I think that's a reasonable goal. That's not how the Debian release process works. If everything goes well, that package may hit testing next week[0]; and it may very well be that the next stable release will be in two years. [0] https://tracker.debian.org/pkg/openssl https://tracker.debian.org/pkg/openssl
    - 9y ago
thinkMOAR 9y ago
Also for MTAs? That's a bold move :)
snvzz 9y ago
What's appalling is how they're not switching to libressl yet.
user5994461 9y ago
Can we have a reminder, what is the security issue with TLS 1.0 and TLS 1.1?
- hannob 9y ago
  The main issue is lack of authenticated encryption and in consequence padding oracles. It turned out that fixing them thoroughly is extremely difficult. Again and again new variants of these attacks have been found and existing countermeasures have turned out to be insufficient. While these attacks are of low impact (involves timing and that's hard to pull off remotely), it's certainly not something you want in the most important crypto protocol. TLS 1.0 has additional issues, notably the BEAST attack. All of that can be mitigated, but it's ugly and complicated and you really just want authenticated encryption (AES-GCM or Chacha20-Poly1305), which is only available in TLS 1.2.
  - baby 9y ago
    A good TLS 1.1 server implementation implementing all the fixes should be "fine". While a good TLS 1.0 client implementation should prevent the BEAST from working. Note that all of these could run without problems if both side support the encrypt-then-MAC extension (https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366). It's a lot of "if" though, hence why we prefer TLS 1.2 which has no problems (so far). But usually when nothing do, it is still better to have something than nothing. If you want to know more about BEAST: https://www.cryptologie.net/article/413/beast-an-explanation-of-the-cbc-padding-oracle-attack-on-tls/ https://www.cryptologie.net/article/413/beast-an-explanation...
DCKing 9y ago
Last year I disabled TLS 1.0/1.1 on my personal server and encountered problems. Turns out Mono (Keepass2Android) and Qt (QBittorrent) libraries on Android for some reason had not enabled higher-than-TLS-1.0 support, although AFAIK they supported it at the time. So yeah, I ended up reenabling TLS 1.0/1.1 on a system on which I had full control over the clients connecting to it. Given the difficulty and nature of current attacks, I figured the low risks to me personally weren't worth the inconvenience. I commend the Debian project for making the push for this, but I wonder if the world is ready to be TLS 1.2+ only.
snakeanus 9y ago
I also have disabled all versions before TLS 1.2, any key exchange other than x25519 (I wanted to avoid the NSA curves) and all encryption/mac algorithms other than Chacha20-poly1305. It works just fine with the last Firefox ESR and Chromium that way.

147 points by jhealy 9y ago

chickenbane 9y ago

Good. Debian won't be making stable any time soon, so a very reasonable timeline.

pilif 9y ago
I don’t know. We have customers connect to us with their internal systems they haven’t touched in ages. I can’t possibly tell them that they need to update their infrastructure two years (Debian has a two year release cycle and has released this year) from now. And then there are some end-users behind enterprise middle-boxes which don’t support anything beyond TLS 1.1 and I have a feeling it’s going to be difficult to communicate to them that they need to change the configuration. This means that we'll have to package our own FTP and HTTP servers in the future. Not a big deal, but certainly not something I'm looking forward to. Oh and our mail relay I probably have to build myself too or just disable TLS. You have no idea what shitty SSL configurations are used out there by the various systems trying to send us email. Grumble. At this point, I might as well run Linux from scratch when most of the daemons we run won't be able to talk to a seizable chunk of the clients connecting to us any more. In other words: if you set up Debian out of the box today, its default packages will talk to 99% of clients out there on the internet. If you set up Debian in 2019, about 30% of the clients out there won’t be able to talk to you. And the fix won’t just be a configuration change; it will require you to manually build every single daemon you make use of.
- throwaway2048 9y ago
  I think introducing some friction here is a good idea, pre 1.2 tls/ssl are objectively broken, insecure protocols. Unless some of these people experience some pain and fix their shit, they will never upgrade, and by extension keeping everyone that wishes to communicate with them vulnerable as well (due to BAD_GUY being able to force protocol downgrades) Is it the right solution to accommodate them (not to mention by default out of the box which means it hurts your users without them being aware of it or able to make an informed choice) and pretend it isn't a problem, and thus putting yourself at risk too? For the same reasons i think its highly irresponsible people like FreeBSD patch in garbage like null cipher support into ssh. It is broken let the people who have to use it for whatever weird reason deal with the burden of their broken shit, don't force it on everyone else and weaken their security.
  - pilif 9y ago
    > not to mention by default out of the box sure. Disable it by default, but leave it compiled in, so an admin can re-enable it by changing a config setting instead of recompiling half a distro. > and thus putting yourself at risk too I'm not at risk if some big restaurant chain orders their supplies over TLS 1.1 instead of TLS 1.2. I'm not at risk if their email server sends us support tickets over TLS 1.1 instead of 1.2. However, my business is at risk if they can't order their supplies and if I then can't receive the support email telling me so. > patch in garbage like null cipher support into ssh there's a huge difference there: null-ciphers are completely pointless and no known client out there only supports null-ciphers. But about 30% of the internet doesn't support TLS 1.2.
    - throwaway2048 9y ago
      Its unfortunate that this situation causes you problems, but there is literally no other way that some people will ever upgrade their shit, you could wait 10 years and they will still be using tls1.1. Its important to at least make it harder than flip some switch and forget about it forever, or nothing is going to change.
      - pilif 9y ago
        (Edit: this reply is a reply to a your comment before your edit that stated I was at risk because of non-mitigatable issues in 1.1) My 1.1 supporting customers are at risk. I'm not at risk. If they take the (unwise) decision that the risk of their connections being eavesdropped is less significant that the amount of work it takes to update their internal network, than its their decision. I am absolutely not in the position to do advocacy there. And neither are other companies who have to serve enterprise customers. „But allowing 1.1 will allow attackers to force secure 1.2 supporting clients to downgrade“ you might say. To which I reply: why are they still supporting 1.1? If they are security conscious enough to update their infrastructure to support 1.2, they can disable anything else when talking to me.
        madez 9y ago
- bigbugbag 9y ago
  I am confused with your two years figure. With a two year release cycle in two years testing will become stable, but this change is in unstable which will become testing in two years. Or did I miss something here ?
  - 0x0 9y ago
    Packages in unstable can enter testing in 2-10 days, not years :) https://wiki.debian.org/DebianTesting https://wiki.debian.org/DebianTesting
    - jwilk 9y ago
      To be pedantically correct, the 2 days limit is incorrect. An upload with priority=emergency can be accepted to testing without extra delay.
- pdw 9y ago
  Would it really be necessary to rebuild all daemons? It seems to me that it would be sufficient to drop in a custom libssl that doesn't disable the old protocols.
  - Conan_Kudo 9y ago
    Depends if the protocol change affects the API and ABI. I think with OpenSSL, it might. But I'm not sure about that...
- rlpb 9y ago
  > At this point, I might as well run Linux from scratch... You might as well learn the Debian tooling and run a system with the OpenSSL package patched with a build-time change. On Ubuntu, that'd be the same as maintaining a PPA with one source package in it. On Debian, it's effectively the same except that you'll need reprepro or a script around apt-ftparchive instead. This is far easier than your hyperbole of running Linux from scratch.
- Twirrim 9y ago
  At a previous job they finally deprecated RC4-MD5, long after almost everyone had stopped using it. About a week later they had to re-enable it, because it turned out a few major customers had some old SPARC (IIRC?) boxes that used the service. The extra overhead of non RC4-MD5 ciphers was crippling them. There was some seriously frantic back and forth with the customer to get the situation resolved and figure out a timeline to finally, finally, finally deprecate RC4-MD5.
- yuhong 9y ago
  How many years do you estimate.

koolba 9y ago

Is there a plugin or setting for Firefox or Chrome that would give me stats on server protocol support for my own interactions? I'm pretty sure the preference is newer versions of TLS where available. So would be interesting to see if this would have any impact on ones own browsing habits (ignoring the fact that FF has its own TLS lib so wouldn't be using OpenSSL anyway).

mholt 9y ago
The inspector tools of both Firefox and Chrome will give you the protocol version and cipher suite selected.
- sitkack 9y ago
  I am bummed that Chrome removed it from info tip over the lock icon. One has to dive into the developer tools tab to get this info now.
  - microcolonel 9y ago
    Yeah, it's really inconvenient and slow, I'd chime in if you want to file a bug report.
    - snailmailman 9y ago
      I mentioned in another comment but may as well put it here too. chrome://flags/#show-cert-link has a workaround that puts it back in a more easily accessible location in the dropdown from top left (where the site permissions currently are)
  - snailmailman 9y ago
    In the new chrome 60+, you can go to chrome://flags/#show-cert-link and then it can be found through a link under "view site information" again. just learned this the other day, a setting thats very well hidden.
    - 9y ago

rossy 9y ago

This makes me anxious, but I'm not sure if my anxiety is valid. I didn't know it was okay to disable TLS 1.0/1.1 this early. Correct me if I'm wrong, but this will affect all HTTPS web requests and web serving, as well as mail delivery and receipt from Debian sid. I'm not sure I want to only be able to surf ~90% of the encrypted web[1] and I'm not sure I'm ready to drop support for Android 4.3[2] or stock Windows 7/IE (which has TLS 1.2 switched off in Internet Options.) Not to mention all the mail servers out there running outdated crypto. I have mail in my inbox (from eg. Amazon Pay) received over TLS 1.0. As far as I understand, supporting outdated protocols like TLS 1.0 is only a problem if there is a downgrade attack that can force a server and client that speak TLS 1.2 to communicate over TLS 1.0. Otherwise, it should be fine to support TLS 1.0 to speak to older clients, while giving newer clients the option to speak over TLS 1.2. Hopefully this announcement is correct in the assumption that support for TLS 1.2 will be high enough when Buster is released. [1]: https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/ [2]: https://www.ssllabs.com/ssltest/clients.html https://www.ssllabs.com/ssltest/clients.html

cft 9y ago
Yes, you can't run a webserver on that Debian that supports tls with Android 4.3 or earlier for example.
- pmlnr 9y ago
  I'm pretty certain you're being sarcastic, but on Debian, most of the users stick to the "stock", packaged ones, instead of building their own. Indeed you can build nginx with custom ssl, but most of the Debian users won't fiddle with this.
vbernat 9y ago
Browsing shouldn't be affected as it doesn't use OpenSSL. However, I share your concerns. The target is the next stable (two years), but many of us are running unstable or testing.
- Conan_Kudo 9y ago

0x0 9y ago

Seems a little risky especially for SMTP services. Will be interesting to see how this pans out!

hannob 9y ago

I predict hereby that this change won't last long. While cryptographically it's the right move (everything below TLS 1.2 with an AEAD is cryptographically broken), this disables connectivity with half of the Internet. There is a huge number of hosts out there running on legacy hardware that won't do anything beyond TLS 1.0.

bigbugbag 9y ago
And those hosts ought to up their game or disappear. The other way to look at it is that you have security vulnerabilities because a portion of the internet is stuck in a decade old obsolete world.
- r1ch 9y ago
  It's not just about hosts. In developing countries, old generation mobile phones running Android 4.x are extremely common. Google's own metrics show 26% of Android phones are pre-5.0, and that's without the unknown number that don't have Google Services installed. EDIT: Seems the last version of Android 4 does support TLS 1.2, but there's still a non-zero amount of users on older versions.
codemusings 9y ago
We're talking Debian Unstable. That change is at least 2 years out if you're running Testing on your servers or 4 years with Stable. I think that's a reasonable goal.
- mmarx 9y ago
  > That change is at least 2 years out if you're running Testing on your servers or 4 years with Stable. I think that's a reasonable goal. That's not how the Debian release process works. If everything goes well, that package may hit testing next week[0]; and it may very well be that the next stable release will be in two years. [0] https://tracker.debian.org/pkg/openssl https://tracker.debian.org/pkg/openssl
  - 9y ago

thinkMOAR 9y ago

Also for MTAs? That's a bold move :)

snvzz 9y ago

What's appalling is how they're not switching to libressl yet.

user5994461 9y ago

Can we have a reminder, what is the security issue with TLS 1.0 and TLS 1.1?

hannob 9y ago
The main issue is lack of authenticated encryption and in consequence padding oracles. It turned out that fixing them thoroughly is extremely difficult. Again and again new variants of these attacks have been found and existing countermeasures have turned out to be insufficient. While these attacks are of low impact (involves timing and that's hard to pull off remotely), it's certainly not something you want in the most important crypto protocol. TLS 1.0 has additional issues, notably the BEAST attack. All of that can be mitigated, but it's ugly and complicated and you really just want authenticated encryption (AES-GCM or Chacha20-Poly1305), which is only available in TLS 1.2.
- baby 9y ago
  A good TLS 1.1 server implementation implementing all the fixes should be "fine". While a good TLS 1.0 client implementation should prevent the BEAST from working. Note that all of these could run without problems if both side support the encrypt-then-MAC extension (https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366). It's a lot of "if" though, hence why we prefer TLS 1.2 which has no problems (so far). But usually when nothing do, it is still better to have something than nothing. If you want to know more about BEAST: https://www.cryptologie.net/article/413/beast-an-explanation-of-the-cbc-padding-oracle-attack-on-tls/ https://www.cryptologie.net/article/413/beast-an-explanation...

DCKing 9y ago

Last year I disabled TLS 1.0/1.1 on my personal server and encountered problems. Turns out Mono (Keepass2Android) and Qt (QBittorrent) libraries on Android for some reason had not enabled higher-than-TLS-1.0 support, although AFAIK they supported it at the time. So yeah, I ended up reenabling TLS 1.0/1.1 on a system on which I had full control over the clients connecting to it. Given the difficulty and nature of current attacks, I figured the low risks to me personally weren't worth the inconvenience. I commend the Debian project for making the push for this, but I wonder if the world is ready to be TLS 1.2+ only.

snakeanus 9y ago

I also have disabled all versions before TLS 1.2, any key exchange other than x25519 (I wanted to avoid the NSA curves) and all encryption/mac algorithms other than Chacha20-poly1305. It works just fine with the last Firefox ESR and Chromium that way.