AnsweredAssumed Answered

Is there a reason for still having TLSv1.1 enabled?

Question asked by Mike Owens on Aug 31, 2016
Latest reply on Sep 6, 2016 by Rob_T

I was looking at our logs, and then our SSLLabs report, and I can see no reason to keep TLSv1.1 enabled on our servers, and a good reason to disable it.  Researching this came up with little, except this thread here from 2+ years ago:

 

> How about disabling TLSv1.1 leaving 1.0 and 1.2 ?

 

I think Geert Hendrickx was on to something then, and his points are even more true now:

  • We still see too many TLSv1.0 handshakes to ignore, primarily from older Android devices.  So disabling TLSv1.0 is a no-go for the moment, even though it'd be nice.
  • TLSv1.2 is the current deployed state of the art protocol and widely supported amongst clients.  We actively want this.
  • A TLSv1.1 handshake in the wild looks really rare from where I'm standing.  Even though I know and remember the history, in 2016, it looks as if all clients that moved beyond TLSv1.0 implemented TLSv1.1 and TLSv1.2 on the same day.

 

We've ended up in a spot where all (for a reasonable definition of "all") clients either request and get TLSv1.2, or must fallback to TLSv1.0 because they don't support anything newer.  This includes non-browser clients.

 

We're not waiting for implementations: each of the vendors who's old clients are now getting TLSv1.0 have moved on and support TLSv1.1 and TLSv1.2.  We're basically waiting for clients to upgrade, and I have no reason to believe that when they do, they'll end up with code that supports TLSv1.1 but not TLSv1.2.  I don't think there's a wave of TLSv1.1 over the horizon.

 

I'll devil's advocate some things I think are non-reasons to continue supporting TLSv1.1:

 

  • TLSv1.1 is a more modern protocol than TLSv1.0:  This is true, but nothing is using it, and modern clients have access to TLSv1.2.  When old clients are upgraded or are replaced, they'll be using TLSv1.2, not TLSv1.1
  • TLSv1.1 is still in active use: My personal experience shows this is not the case, but evidence to the contrary shuts down this entire argument.  We have an extremely varied device list accessing our service regularly, from $40 throwaway smartphones to automated Perl user agents, however, most of our user agents are in North America.  Unless I'm missing a lot of TLSv1.1 clients in other regions, I'll have to believe they're not there.
  • It's weird to have the version gap.  Yeah, it doesn't feel right, but I also had to support IE 6 while 7 and 8 came and went.
  • It does no harm to leave it enabled: This is the big one.  I think having a security-critical codepath, exposed externally, that is only exercised by Qualys' test is a bad security practice.  We've seen this a handful of times in the last few years with OpenSSL.

    If the spec or our implementation of TLSv1.0 ends up vulnerable in the future, we'll take the black eye with the rest of the industry, because we needed the protocol support.  If a vulnerability ends up being specific to TLSv1.1, I'd have a hard time answering why we had it enabled, because I knew before-hand that we got nothing in return for having it enabled.

 

Can an argument can be made that supporting TLSv1.1 now will hasten migration off of TLSv1.0?   I'd consider that compelling.  I don't know what forces would have to be at play for that to happen, though.  Are people seeing more TLSv1.1 handshakes than we are?  I'd love to see any arguments I've overlooked.

Outcomes