OpenSSL in Debian Unstable drops TLS 1.0/1.1 support
lists.debian.org
lists.debian.org
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/ [2]: https://www.ssllabs.com/ssltest/clients.html
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.
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.
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.
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.
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.
Packages are not promoted into (out of?) testing unless they don't have open issues reported against them. If this concerns you, then the right thing to do is to file an issue. Keep it open long enough and this won't make it into the next stable release.
If necessary, someone will create a dotdeb-equivalent for an openssl version with TLS 1.0. This is a "dammed if you do, dammed if you don't" type of thing. If they don't disable it, at the next big security issue, everyone will blame openssl/distributions for being negligent.
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.
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.
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.
Its important to at least make it harder than flip some switch and forget about it forever, or nothing is going to change.
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.
Okay with being eavesdropped? Do it unencrypted.
Not okay with being eavesdropped? Use not broken cryptography.
I'm not making this up.
After all, Debian is set to give the process of change 2 years. That is plenty of time for updating the regulation and processes.
Also, you can stay on oldstable for a while if you absolutely cannot upgrade.
Funny enough, it tried to deprecate old TLS versions already but it was so widely used that they had to move back the date.
https://blog.pcisecuritystandards.org/migrating-from-ssl-and...
https://support.cloudflare.com/hc/en-us/articles/205043158-P...
If I did that, I think Debian would not change their software to meet my bizarre "company regulations"
If Debian comes out in 2019 in a state where 30% of the internet can’t talk to it without recompiling the daemon packages, then people will switch to „more compatible“ distros.
I have the infrastructure to quickly deploy patched packages, so for me this is just an annoyance (also because these self-built packages I have to security-patch myself, which is actually putting me at risk), but others don’t. For them this will be a reason to switch distros
And Firefox and Chrome can be behind middleboxes and/or personal firewalls that only talk TLS 1.1 on the public-facing side.
And finally, there's a lot of android devices running Android < 5 which all don't support TLS 1.2 and never will.
When I talk to my virtual machines over the loopback device, I have to encrypt and then decrypt the traffic. That is pointless. I wish my SSH supported the null cipher.
That's very risky.
If it supported the null cipher by default, users would be a single misconfiguration away from losing all security. By forcing the few who have a legitimate need for a null cipher to patch and recompile, this risk is reduced.
It's the same reason reputable crypto libraries avoid implementing things like the TLS null cipher suites (they exist), and also why the new TLS 1.3 protocol has only PFS suites and AEAD.
Or did I miss something here ?
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.
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.
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.
Note that all of these could run without problems if both side support the encrypt-then-MAC extension (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...
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).
just learned this the other day, a setting thats very well hidden.