OpenSSL Support In Debian Unstable Drops TLS 1.0/1.1 Support (debian.org) 76
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.
PCI Compliance (Score:4, Informative)
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 (Score:1)
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: (Score:2)
This generally IS done, but can be easily abused.
Re: (Score:3)
Re: (Score:3)
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 p
Re: (Score:3)
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,
Re: (Score:1)
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: (Score:2)
Re: (Score:1)
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: (Score:1)
Re: (Score:3)
Since the entire purpose of TLS is to provide security, then insecure equals broken.
Re: (Score:3)
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 ne
Re: (Score:2)
It is deliberately removing broken things.
TLS 1.0 is not broken.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:2)
Re: (Score:3)
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: (Score:2)
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!
Re: (Score:2)
How clever of you to insert this crap into yet another thread. You're changing the world ,man!
Good. (Score:2)
Re: (Score:2, Troll)
Re: (Score:2)
can't patch them
Convenient that they can't patch and the only recourse is buying half a mil of new equipment...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
That's always the answer around here. Having problems with $MYTECHRELIGION? Must be because you're an idiot because $MYTECHRELIGION is infallible!
Re: (Score:2)
Build an in-house SMTP proxy that accepts v1.0+ and connects out as 1.2?
Re: (Score:3)
Some Debian devs are running amok, again (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
Just my point. But apparently this thing is now in the hands of somebody both inexperienced and too arrogant to know that.
Re: (Score:2)
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: (Score:2)
And all you have now done is to confirm my analysis. Well done! And yes, "authoritarian asshole"!
Re: (Score:3)
Centos6 (supported until 2020) does not support TLSv1.2 for its php-curl (command line curl works with TLSv1.2 IIRC).
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
IE11 supports TLS 1.2 fine. Earlier versions of IE are not supported anymore.
Deprecating != Disabling (Score:2)
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.
Debian Unstable is a misnomer! (Score:3, Informative)
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 be
How many packages does it actually impact? (Score:3)
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: (Score:2)
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 rel
Re: (Score:2)
apache, postfix and nginx come to mind as common packages that use openssl.
Re:How many packages does it actually impact? (Score:4, Informative)
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.