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.

Comments

PCI Compliance

[darkain]

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.

Re:PCI Compliance

[adosch]

Agreed. Those of you that do have strict PCI compliance pushing this I can totally get behind. However, this is yet another think-before-acting approach and anyone who's married to any sort of Debian distro love. The pace of catch-up is just going to cause compatibility issues and if you think hand-rolling-and-replacing your openSSL integration on your distro with source is fun to get 1.0/1.1 support back? Think again. I'd rather be stung by 10,000 bees with a bucket of ice cream and a dozen roses in my lap.

I do disagree that havingTLS 1.0/1.1 enabled makes audit failure; it's still widely adopted and if you're not getting paid audits, pen testing or security scanning from a 3rd party giving you a paid and overly cautious analysis to be paranoid-secure, then it's 80-90% good for the rest of the world with public facing. I've always used SSL Labs as at least a 'me' benchmark for anything I do SSL anything and I don't see 1.0/1.1 as a blackmark on that, so it's hard for me outside someone, some entity or some policy driving it at my work or project, that it's still viable. Because it beats not having anything at all or using any SSLv2/3 crap.

Re:PCI Compliance

[WaffleMonster]

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.

There is nothing wrong with TLS 1.0 that would lead to any real world threats vs 1.2. Forcing people to do something without even bothering to present a rational justification is poor policy and poor governance.

There have been numerous actual exploitable threats created with the introduction of new features in TLS stacks.

Re:PCI Compliance

[Wrath0fb0b]

Since the entire purpose of TLS is to provide security, then insecure equals broken.

Re:PCI Compliance

[skids]

It is deliberately removing broken things.

The world runs on broken things. Thiis move might even be bad for global security given some of the
half-assery that is bound to happen to work around it for stuff that PHBs consider "too critical to upgrade."
Wonder how many 3rd party distro servers will pop up offering backwards compatible OpenSSLs and how
many people will just grab them in desperation while trying to make a deadline.

The coulda/woulda/shoulda here is that any protocol allowing version and parameter negotiation really ought
to protect that negotiation.

Even IKEv2 got this wrong, though you can work around it if you've got some extra RAS IPs to burn.

Incidentally, anyone know if Apple is doing TLS1.2 yet for dot1x? If not, that'll be fun to watch.

Some Debian devs are running amok, again

[gweihir]

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.

Re:Some Debian devs are running amok, again

[hackel]

That's nonsense. It is still opt-in. All you need to do is compile the packages yourself. It's reall not complicated. Why should Debian choose to allow insecure software that they are responsible for releasing security patches for? That makes no sense at all. "Authoritarian asshole?" Really? What have you contributed to the community lately?

Re:Some Debian devs are running amok, again

[G00F]

compiling oneself is hackish in that when something gets patched, you need to rebuild it again. Thus also shows why it's less secure because the unpatched version will run longer.

Now do this for a small company with only a handful to a few hundred systems. They had to compile this themselves for some backwards compatibility with some vendor or software, and now it may never get patched again.

Thus it's more secure to have it disabled by default rather than have it compiled out.

Re:Some Debian devs are running amok, again

[Pentium100]

Centos6 (supported until 2020) does not support TLSv1.2 for its php-curl (command line curl works with TLSv1.2 IIRC).

How many packages does it actually impact?

[Mousit]

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.

Re:How many packages does it actually impact?

[Mousit]

apache, postfix and nginx come to mind as common packages that use openssl.

Good point. I don't run web services on that server so I didn't even think to look at those packages. That'd be a pretty big deal if the major web servers in Debian need it.

I did do some digging around after making that earlier post. I can definitely see from the client end it'll really make an impact for sure. In particular it's rather frightening how many SMTP servers out there don't do TLS 1.2 at all, so good luck being an MTA talking to other servers. Even Apple and Google/Gmail SMTP servers only talk TLS 1.0. No 1.1 or 1.2 support. Those are two companies I'd have figured would be at the forefront of such support. Amusingly their IMAP servers support 1.2 just fine. So, with those two, you can GET your mail but you can't SEND your mail in a 1.2-only environment. :)

Debian Unstable is a misnomer!

[Anonymous Coward]

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.

Re:Good.

[Anne Thwacks]

That is the exact job people used to use Debian for.

Re:beta testing TLSv1.2-only

[WaffleMonster]

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.

Re:beta testing TLSv1.2-only

[arglebargle_xiv]

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".