From the announcement mailing list:


I’ve just uploaded a version of OpenSSL to unstable that 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.

The problem with TLS 1.0

The TLS 1.0 suffers from a lack of authenticated encryption in CBC chaining attacks and padding Oracle attacks:

TLS 1.0 is still widely used as the ‘best’ protocol by a lot of browsers that are not patched to the very latest version. It suffers from CBC Chaining attacks and Padding Oracle attacks. TLSv1.0 should only be used after risk analysis and acceptance. PCI DSS 3.2 prohibits the use of TLS 1.0 after June 30, 2018.

TLS 1.0 also suffers from the BEAST attacks and mitigation is complicated or ugly. Hence everyone avoiding TLS 1.0. However, there is a big issue moving to TLS 1.2.

What does it mean for Debian sid users and mobile/desktop clients?

First of all, support dropped for Debian Unstable i.e. this change will take effect on Debian Linux 10 only. 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 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 You can check your browser’s TLS 1.2 compatibility using at

Fig.01: User Agent Capabilities

Fig.01: User Agent Capabilities

How do I find out server TLS protocol support for my browser?

Use the following plugins/addons:

  1. CipherFox – Displays the current SSL/TLS cipher, protocol and certificate chain in the Add-on bar and Site ID dialog.
  2. SSleuth – How strong is your HTTPS connection? SSleuth ranks an established SSL/TLS connection and gives a brief summary of the cipher suite, certificate and other SSL/TLS parameters.
  3. You can use the Google Chrome developer tools to get this info too.

Fig.02: CipherFox in action


Fig.03 SSleuth on action

Poll: Are you on a strict diet of TLS 1.2 only for your server?

Overall this makes me concerned especially in SMTP servers and client support departments. I suggest Debian maintainer give an option to keep TLS 1.0/1.1 as I deal with many legacy clients. Correct me if my concerns are not valid below in the comments section.

🥺 Was this helpful? Please add a comment to show your appreciation or feedback.

nixCrat Tux Pixel Penguin
Hi! 🤠
I'm Vivek Gite, and I write about Linux, macOS, Unix, IT, programming, infosec, and open source. Subscribe to my RSS feed or email newsletter for updates.

3 comments… add one
  • Norman Rasmussen Aug 8, 2017 @ 1:09

    If you need TLS 1.0/1.1 today then you shouldn’t be using unstable. Hopefully things will look better by the time Buster is released, otherwise the change could always be reverted, or an insecure alternate package be made available, but really TLS 1.0 & 1.1 are insecure enough that it’s past time to migrate off them.

  • Nigratruo Aug 8, 2017 @ 2:51

    Please read up on what debian unstable is for, definitely NOT for a productive system, unstable’s motto is “expect breakage, you have been warned!”
    I think somebody is not getting this here.

  • Jane Aug 8, 2017 @ 11:05

    Your concerns are misguided. If you care about security then you migrate everything to TLSv1.2. If you don’t, then you migrate to unencrypted protocols.

    There is no moral or business case to keep running insecure “encrypted” protocols.

Leave a Reply

Your email address will not be published. Required fields are marked *

Use HTML <pre>...</pre> for code samples. Your comment will appear only after approval by the site admin.