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

[Anonymous Coward]

Why can't the software involved with the credit card processing just disable versions of SSL or TLS deemed unsuitable at the configuration level?

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

[msauve]

It is not a MUST. It is deliberately breaking things. Even if TLS 1.0 support is possible, YOU have the ability to disable its use if you can't use it for some reason.

Re:PCI Compliance

[Anonymous Coward]

Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes ...in case you're not kidding around.

Re:PCI Compliance

[Anonymous Coward]

That might be true but a lot of people underestimate the number of things that are NOT public facing that are out there, still in use. I would give my left nut for a browser that had a setting which said "I don't give a crap if it's a self signed certificate. I have hundreds of internal network devices that I access on a dedicated management network which have self signed certs. Just accept the damned things and shut up." The number of TLS 1.0 devices is small but NOT zero. I have no problem with TLS 1.0 being deprecated and even disabled by default. But give me the option of enabling it if I need it.

Re:PCI Compliance

[Anonymous Coward]

It is not a MUST. It is deliberately breaking things. Even if TLS 1.0 support is possible, YOU have the ability to disable its use if you can't use it for some reason.

It is deliberately removing broken things.

Re:PCI Compliance

[rastos1]

"I don't give a crap if it's a self signed certificate. I have hundreds of internal network devices that I access on a dedicated management network which have self signed certs. Just accept the damned things and shut up."

What about running your own little CA, using it to generate certs for the devices on your network and importing the CA cert to your browser?

Re:PCI Compliance

[Train0987]

Was there anything stopping you from disabling it on your side without breaking it for the whole world?

Re: PCI Compliance

[Anonymous Coward]

He shouldn't have to waste time and effort on something like that. The browser should make it trivial to accept self-signed certs from just a list of allowed hosts and IPs.

Re: PCI Compliance

[hackel]

That is effectively equivalent to removing SSL entirely. I'm sure glad I don't have someone like you in charge of my internal security.

Re: PCI Compliance

[lactose99]

This generally IS done, but can be easily abused.

Re:PCI Compliance

[Anonymous Coward]

"I don't give a crap if it's a self signed certificate. I have hundreds of internal network devices that I access on a dedicated management network which have self signed certs. Just accept the damned things and shut up."

What about running your own little CA, using it to generate certs for the devices on your network and importing the CA cert to your browser?

In this particular case? Because I'm a network engineer working a support contract for someone else's network and I have no say at all in how it's configured. I simply figure out what went wrong when things break.

Re: PCI Compliance

[Anonymous Coward]

That is effectively equivalent to removing SSL entirely. I'm sure glad I don't have someone like you in charge of my internal security.

Please explain to me how this is more dangerous that an entire team of people who have been effectively trained to expect and automatically click through a series of warnings in order to reach a device. When you access dozens of devices every day and each one of them gives you a series of warnings that you have to bypass and you can click through them with your eyes closed, are you really arguing that those warnings are effective and make you safer?

Re:PCI Compliance

[Pentium100]

Chrome has it, use the command line parameter --ignore-certificate-errors

But be careful, this will ignore ssl errors for all sites - it will still display the red "https" in the address bar, but it will not display the error.

Re:PCI Compliance

[Train0987]

Insecure does not equal broken. Insecure equals insecure.

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

[Anonymous Coward]

No, it's not. You apparently don't understand the differences between authentication and encryption, and you apparently don't understand what whitelisting is.

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.

Re: PCI Compliance

[skids]

That is effectively equivalent to removing SSL entirely

Not quite. First, it does still protect you against eavesdrop-only attacks. Second I think what
they mean is to just accept them on first contact but pin them thereafter, which is still a bit
dicey, but a heck of a lot better than allowing them to change.

Re:PCI Compliance

[WaffleMonster]

It is deliberately removing broken things.

TLS 1.0 is not broken.

Re: PCI Compliance

[Anonymous Coward]

The GP is obviously incompetent, and unable to do his job correctly.

Re:PCI Compliance

[tajribah]

This assumes that the certificates on the devices are configurable. Alas, on many real devices they aren't - just a self signed cert generated by the device's firmware.

Re: PCI Compliance

[Anonymous Coward]

systemd is broken. Can they remove that as weLloyd

Re: PCI Compliance

[Anonymous Coward]

Hmm my auto complete is broken as well

Re:PCI Compliance

[Anonymous Coward]

Pfff... When I was working at Google cleaning out IT closet for 35K we used to use USB Compliance. PCI Compliance is a pain in the butt...
-criemer

Re:PCI Compliance

[x_t0ken_407]

Gawd I remember the hell that was being in-charge of PCI compliance for a website & associated mobile apps. I feel your relief here, brother lol!

disabled at compile time, or just default ciphers?

[Anonymous Coward]

My question is, is this just a runtime default, or have they disabled TLS 1.2 at compile time? If it's just the default, I see no problems here. If its compile time, they need to go suck it.

Re:disabled at compile time, or just default ciphe

[Anonymous Coward]

Welcome to Linux. Every new release, more stuff mysteriously broken.

Good.

[QuietLagoon]

I've been supporting "TLS 1.2 only" on my webserver for about a year now.

Re:Good.

[Train0987]

Congrats! How many $10k+ multi-function devices do you have that will only scan-to-email to the mail server with TLS 1.0? I've got about 50. Will you loan me the half-mill meeded to upgrade those since Xerox can't patch them?

Re:Good.

[Junta]

can't patch them

Convenient that they can't patch and the only recourse is buying half a mil of new equipment...

Re:Good.

[hackel]

Don't blame other people because you or your company was idiotic enough to buy shitty hardware. Learn your lesson and move on. Don't drag everyone else down with you.

Re:Good.

[Train0987]

There are legit firmware size limits for some of the older models. I still have a couple that don't support any encryption at all because of that (including that code in the firmware now exceeds the size of the flash). But for the most part yes, they push you into newer models. It's hard to blame them though since there's nothing functionally wrong with TLS 1/1.1 and can be made secure if kept on the internal LAN.

Re:Good.

[Anonymous Coward]

Indeed, especially since in many parts of the world, you can actually sue them into either paying for the replacement OR fixing the dang things.

However, you CAN always add an US$100 small box running Debian or FreeBSD or whatever brand of Linux/BSD you like most, install a mail relay agent there that does ESMTP without TLS *and* TLS1.2, and configure the scanners to send to this box, and get the box to forward it over TLS to your corporate server. Use a VLAN or a small switch, or if you use LEDE/OpenWRT to do it, a US$ 50 SOHO router with an embedded switch, and isolate the non-LTS side from the network, thus protecting privacy.

See, US$100 per printer (or, if you can do corporate VLANs properly, US$ 100 per the entire building), and you are now a lot more secure since people won't be able to trivially trojan these Xerox monsters (or did you think the lack of TLS 1.1 and 1.2 are their only problem?!)

Re:Good.

[lactose99]

Build an in-house SMTP proxy that accepts v1.0+ and connects out as 1.2?

Re:Good.

[Train0987]

Actually it's a local government that made a very large investment a few years ago. This is tax dollars and your reply is that they bought shitty hardware so they deserve it? Thank God you don't work for me or anywhere else that budgets tax-payer funds.

Re:Good.

[Train0987]

Except the devices aren't broken. They work exactly as designed. If I were running an internal Debian mail server and got borked by this then Xerox will claim that the problem is with my server, not their hardware.

Re:Good.

[Anne Thwacks]

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

Re:Good.

[cyber-vandal]

You do know that suing takes a lot of time and plenty of money, and in the meantime the devices are not working and the business is demanding you do something about it. Your fix might work but won't be supported by Xerox and they will quite happily blame that while still taking your money and doing nothing. You're very lucky you work in an environment where you can choose exactly what hardware and software you can work with but the rest of us have to deal with other people's purchasing decisions.

Re:Good.

[cyber-vandal]

That's always the answer around here. Having problems with $MYTECHRELIGION? Must be because you're an idiot because $MYTECHRELIGION is infallible!

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

[Anonymous Coward]

>All you need to do is compile the packages yourself. It's reall not complicated.

Openssl? Not complicated? Oh man.

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]

I agree that it's an opt-in. All you need to do is continue using the old version and upgrade only when your logs show two consecutive months with no visits from users using browsers that do not support TLSv1.2.

Re:Some Debian devs are running amok, again

[gweihir]

Just my point. But apparently this thing is now in the hands of somebody both inexperienced and too arrogant to know that.

Re:Some Debian devs are running amok, again

[gweihir]

And all you have now done is to confirm my analysis. Well done! And yes, "authoritarian asshole"!

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

Re:Some Debian devs are running amok, again

[Anonymous Coward]

Sounds like you're describing a Windows mindset, not *nix. If someone is frantically looking for the TLS checkbox to click in the Windows GUI they're certainly not going to be able to competently admin a professional OS like Linux or BSD.

For the latter, it's compilation, test, document and deploy. What real admins do everyday anyway.

Re:Some Debian devs are running amok, again

[Anonymous Coward]

Sorry but real admins don't compile stuff. They just build scripts.

Re:Some Debian devs are running amok, again

[Anonymous Coward]

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

Is the answer to "why did you get fired"

Re:Some Debian devs are running amok, again

[thegarbz]

Making it something that need to be explicitly enabled is fine

To be clear you are advocating that someone needs to explicitly enable security?

That is just some authoritarian asshole enforcing their view of how the world should be.

Are you talking about the developers or the hackers and researchers who broke the previous systems?

It also does not make people more secure compared to making it something that needs to be enabled.

Don't smoke weed and post on Slashdot.

Re:Some Debian devs are running amok, again

[gweihir]

Making it something that need to be explicitly enabled is fine

To be clear you are advocating that someone needs to explicitly enable security?

Obviously not. Have you read what this is about? I am, rather obviously, saying that TLS 1.0/1.1 should be disabled by default and TLS 1.2 enabled, but it should be possible to enable TLS 1.0/1.1 as well if needed. There can (and should) be a large warning that this is potentially dangerous, of course.

But I can see from the rest of your posting that you are not interested in facts and probably too stupid to see them when they stare you in the face.

Re:Some Debian devs are running amok, again

[thegarbz]

But I can see from the rest of your posting that you are not interested in facts

Sorry I should have said don't post drunk instead of claiming you smoke weed.

Re:Some Debian devs are running amok, again

[Anonymous Coward]

Why stop at TLS 1.0? Please also suggest bringing back SSL and DES: what was good back then should also be good now; everyone who doesn't agree with you is an authoritarian asshole running amok.

Windows XP and Internet Explorer users

[Anonymous Coward]

Windows XP may not be supported but it still has 6% market share, meaning older TLS versions will need to be supported, Internet Explorer will be supported until at least 2025 in Windows 10 so Debian is at least 8 years early with the TLS switch off. Also Android users can't update their phones due to fragmentation so you're stuck supporting them as well.

Re:Windows XP and Internet Explorer users

[cyber-vandal]

IE11 supports TLS 1.2 fine. Earlier versions of IE are not supported anymore.

Re:Windows XP and Internet Explorer users

[Anonymous Coward]

You're posting garbage. Some browsers in Windows XP already supports TLS 1.2
So XP machines defeats Vista or Win7 which are just using IE. It's not in the OS, it's the user.

Deprecating != Disabling

[hackel]

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.

Re:Good, and deprecate systemd please

[hackel]

How clever of you to insert this crap into yet another thread. You're changing the world ,man!

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?

[skids]

FreeRADIUS will be one, as they use OpenSSL because "everything else is worse." No actually, because SSL's API, though cretinous, doesn't require sessions to be bound to an IO handle, and allows some introspection into the state of sessions that other APIs apparently do not, which is kinda handy when you're handling a large number of really slow negotiations.

In fact, those running FreeRADIUS and using an LDAP backend have to go compile their own OpenLDAP linked against OpenSSL to avoid icky concurrency related crashes caused by GNUTLS's shortcomings.

Re:How many packages does it actually impact?

[petermgreen]

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

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. :)

Re:How many packages does it actually impact?

[Anonymous Coward]

But they got your mail with TLS 1.0 or likely in clear text. MTA->MTA encryption is important too.

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.

beta testing TLSv1.2-only

[Anonymous Coward]

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

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.

Someone has to lead the charge though and this gives everyone a decent amount of notice.

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

Re: disabled at compile time, or just default ciph

[Anonymous Coward]

Well at least they try to improve and or discard old stuff and bring in new stuff. At least they haven't been shipping a broken version of SMBv1 for 20 years