Slashdot Mirror
OpenSSL Support In Debian Unstable Drops TLS 1.0/1.1 Support (debian.org)
An anonymous reader writes: Debian Linux "sid" is deprecating TLS 1.0 Encryption. A new version of OpenSSL has been uploaded to Debian Linux unstable. This version disables the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the only supported SSL/TLS protocol version. This will likely break certain things that for whatever reason still don't support TLS 1.2. I strongly suggest that if it's not supported that you add support for it, or get the other side to add support for it. OpenSSL made a release 5 years ago that supported TLS 1.2. The current support of the server side seems to be around 90%. I hope that by the time Buster releases the support for TLS 1.2 will be high enough that I don't need to enable them again. This move caused some concern among Debian users and sysadmins. If you are running Debian Unstable on server tons of stuff is going to broken cryptographically. Not to mention legacy hardware and firmware that still uses TLS 1.0. On the client side (i.e. your users), you need to use the latest version of a browser such as Chrome/Chromium and Firefox. The Older version of Android (e.g. Android v5.x and earlier) do not support TLS 1.2. You need to use minimum iOS 5 for TLS 1.2 support. Same goes with SMTP/mail servers, desktop email clients, FTP clients and more. All of them using old outdated crypto.
This move will also affect for Android 4.3 users or stock MS-Windows 7/IE users (which has TLS 1.2 switched off in Internet Options.) Not to mention all the mail servers out there running outdated crypto.
This move will also affect for Android 4.3 users or stock MS-Windows 7/IE users (which has TLS 1.2 switched off in Internet Options.) Not to mention all the mail servers out there running outdated crypto.
As someone who had to deal with all the bullshit of PCI Compliance, let me just tell ya. This is an absolute MUST. The current PCI spec strictly states that only TLS 1.2 is supported due to insecurities found in 1.0/1.1. Granted, the PCI group is also overly cautious, but it is good to see more and more software force this spec to make PCI compliance easier. Simply having 1.0/1.1 enabled on anything public facing will fail an audit.
I've been supporting "TLS 1.2 only" on my webserver for about a year now.
Making it something that need to be explicitly enabled is fine. Removing it is not. That is just some authoritarian asshole enforcing their view of how the world should be. It also does not make people more secure compared to making it something that needs to be enabled. It means that people that need it have to use hackish ways to get it and more often than not these will be worse.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
TLS 1.0 and 1.1 have been deprecated for a long time now. Disabling them is a completely different thing.
> "If you are running Debian Unstable on server"
Um, what? Honestly, if you're doing that, you *deserve* to have a hard time.
How clever of you to insert this crap into yet another thread. You're changing the world ,man!
I'm legitimately curious how many commonly installed packages this actually impacts. I was under the impression that Debian tends to default to linking its packages against gnutls instead of openssl due to perceived issues with openssl's licensing versus Debian's license philosophy. Especially most of the "standard" Debian packages.
Just on my own Debian system I only have two installed packages (openssh-server and openssh-client) that depend on the libssl package. I have a dozen common packages (like exim) that are linked against gnutls instead.
People who don't know Debian don't realize that the name "Unstable" is actually a misnomer.
The idea of "stability" and "robustness" has been very different in the Debian world. When it comes to Debian Stable, it's stable in a way that's unheard of for pretty much every other Linux distro out there. These releases have traditionally been as solid as is realistically possible. Most other Linux distros have nothing comparable.
Debian Testing is also extremely stable, when compared to other Linux distros. The best comparison would be to a late-stage bugfix release of a mature Linux distro version.
Debian Unstable, despite its name, is about the level of quality we'd expect from most releases of most other Linux distros. It's only "unstable" when compared to the extreme stability of Debian Stable releases. Otherwise it has traditionally been quite stable.
Remember that Ubuntu's packages are based off of Debian Unstable packages.
Now, things have been changing within the Debian world. Since the introduction of systemd some time ago, things have been going to hell. Quality is down, and user trust is dwindling. Many Debian users have started to move their most important systems to FreeBSD or OpenBSD, which are far more comparable to pre-systemd Debian releases in terms of offering extremely high levels of stability and quality.
But even after the systemd disaster, Debian Unstable is still more stable than even the stable releases of most other Linux distros. It does help Debian's case that its main competitors have also switched to systemd, so their stability and reliability has suffered, as well.
Anyway, when you hear the term "unstable" applied to Debian, keep in mind that we're measuring on a very different scale than is used for most other Linux distros.
IE11 supports TLS 1.2 fine. Earlier versions of IE are not supported anymore.
The maintainer explicitly acknowledges that a rollback may be necessary. But by making this change now, about two years before release, it will allow everyone to start thinking about what can break.
There is no reason to change it now or anytime in the foreseeable future. TLS 1.0 aint broke.
Having it compiled-in is a hard cutoff. One step back would be to have older stuff compiled in, but not negotiated by default--having the application asking the API for support explicitly. One step back from that would be not negotiating TLS 1.0 by default, but allowing 1.1.
As it stands currently it is extraordinarily difficult for applications to select the TLS version they want to use. Choosing to disable TLS 1 requires the following insanely complicated operation:
SSL_CTX_set_options(ctx,SSL_OP_NO_TLSv1);
Someone has to lead the charge though and this gives everyone a decent amount of notice.
Nobody has to lead anything. It's a choice which literally provides no benefit to anyone.
Aside from unnecessary compatibility headaches removal of versions and cipher suites for political rather than real world technical cause means they are no longer available to be selected with haste as backups should implementation or specification bugs be discovered in the future.
There is no reason to change it now or anytime in the foreseeable future. TLS 1.0 aint broke.
Exactly. Sure, there are some nice theoretical attacks that provide essentially no useful foothold for an attacker (but do make for great conference papers, go and look them up if you don't believe me). While it doesn't hurt to go to 1.2 if you've got it, there's no reason to break your whole infrastructure over it. No attacker is going to care whether you're on 1.0 or 1.2.
It's a choice which literally provides no benefit to anyone.
In fact it's a net loss, since you're now going to have to deal with things that don't do 1.2, and may not do 1.2 for years to come, or ever. That's lots of IoT, embedded, SCADA, and legacy gear, for people who are thinking "why can't they just upgrade".