Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Debian Android Security IT Technology

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.

OpenSSL Support In Debian Unstable Drops TLS 1.0/1.1 Support

Comments Filter:
  • PCI Compliance (Score:4, Informative)

    by darkain ( 749283 ) on Monday August 07, 2017 @02:48PM (#54957515) Homepage

    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.

    • by 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?

    • by adosch ( 1397357 )

      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 m

    • by msauve ( 701917 )
      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.
      • by 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.

        • Insecure does not equal broken. Insecure equals insecure.
        • by skids ( 119237 )

          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

        • It is deliberately removing broken things.

          TLS 1.0 is not broken.

    • Was there anything stopping you from disabling it on your side without breaking it for the whole world?
    • 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.

    • 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!

  • I've been supporting "TLS 1.2 only" on my webserver for about a year now.
    • Re: (Score:2, Troll)

      by Train0987 ( 1059246 )
      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?
      • by Junta ( 36770 )

        can't patch them

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

        • 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.
      • by hackel ( 10452 )

        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.

        • 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.
          • That's always the answer around here. Having problems with $MYTECHRELIGION? Must be because you're an idiot because $MYTECHRELIGION is infallible!

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

  • by gweihir ( 88907 ) on Monday August 07, 2017 @03:17PM (#54957703)

    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.

    • by hackel ( 10452 ) on Monday August 07, 2017 @03:54PM (#54957951) Journal

      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?

      • by G00F ( 241765 ) on Monday August 07, 2017 @04:16PM (#54958127) Homepage

        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.

        • by gweihir ( 88907 )

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

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

      • by gweihir ( 88907 )

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

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

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

      • by gweihir ( 88907 )

        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.

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

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

    • by 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 be

  • by Mousit ( 646085 ) on Monday August 07, 2017 @04:02PM (#54958021)
    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.
    • by skids ( 119237 )

      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

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

      • by Mousit ( 646085 ) on Monday August 07, 2017 @08:41PM (#54960227)

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

The IBM purchase of ROLM gives new meaning to the term "twisted pair". -- Howard Anderson, "Yankee Group"

Working...