In light of recent developments on SSL issues such as BEAST and POODLE, I decided to configure my browser to only allow TLS1.1 and higher. The trouble is, that I am finding a lot of websites which do not work correctly (some websites serve all JS and CSS resources as HTTPS always) or at all. A bit of digging usually reveals that there is no cipher overlap, or no protocol overlap. In a lot of cases, I found websites are only accepting maximum protocol version of TLS1.0.

My question is, is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness", and there is no good reason not to allow TLS1.1 and TLS1.2 in addition to TLS1.0?

4 Answers 4


No, there is absolutely no security related reason to continue to support TLS 1.0, but there are several other business concerns which can twist the arm of a system engineer into allowing it. For larger sites, they may be trying not to leave people with older browsers out in the cold. For some situations, the person publishing the website needs to assume you are using I.E 6 with no updates.

It sounds ridiculous, and it is, but it's a fact of life.

That said, if the server doesn't support anything above TLS 1.0, that's a problem no matter how you slice it. You should e-mail them about it. Or, if it's not fixed, stop using the site.

Sometimes it only takes one angry e-mail to set things right.

Edit: I shall emphasize that supporting a legacy operating system or software stack is no excuse for exposing your users to encryption with major known faults.

  • It is not a problem for a server to support both TLS 1.0 for older browsers and TLS 1.2 for newer browsers. The client sends the protocol version it can do and the server then uses the best it can offer to match the clients protocol version. Actually the majority of the servers is setup this way and thus can handle different protocol versions from the clients. Commented Apr 7, 2015 at 21:32
  • Enabling lower versions of TLS leaves you open to downgrade attacks. It would be objectively better to stop offering TLS 1.0, even for older browsers. There is no sound excuse to be using an ancient browser in this age. Commented Apr 7, 2015 at 22:13
  • And I shall add, that if you are justifying keeping TLS 1.0 around by saying you are avoiding an Operating System, or software update, you are practically mortgaging your user's security for your own comfort. Commented Apr 7, 2015 at 22:17
  • 3
    +1 for angry e-mail. This is my current strategy, although my banking site did not take me seriously, and decided to claim that it was implementing "maximum commercially available security", which is obviously laughable. Is there some way to encourage more users to have >=TLS1.1 set in their browser to help find and shame these websites? I cannot do it alone... Commented Apr 10, 2015 at 0:05
  • 1
    I suggest sending them their grade from SSLLab's Server Test ssllabs.com/ssltest/index.html to entice them to up their security.
    – reukiodo
    Commented May 19, 2015 at 1:12

is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness"

It is in most cases just the TLS stack used. One of the most common stacks in web servers on UNIX/Linux is OpenSSL and the still widely used (and supported) versions 0.9.8 and 1.0.0 can do only TLS 1.0 and lower. TLS 1.1 and TLS 1.2 were only added with version 1.0.1 (04/2012). On the Windows side SecureChannel supports TLS 1.1 and TLS 1.2 since Windows 7 and Windows Server 2008 R2 (end of 2009).

And while changing the TLS stack might be doable for some sites it involves is most cases either the upgrade of the operating system or at least to run some parts of the system in a configuration not supported by the vendor.

and there is no good reason not to allow TLS1.1 and TLS1.2 in addition to TLS1.0?

If the server has support for TLS 1.2 there is no real reason to set the server up for only TLS 1.0. In fact, TLS 1.2 not only gives better security but also new cipher suites which can lessen the load on the server.

  • You say that TLS 1.1 and 1.2 were "only" added in OpenSSL three years ago, but that is a really long time. And thats considering that OpenSSL is late to the party in that time to implement them as well... Commented Apr 10, 2015 at 0:02
  • First, 1.0.1 had to mature a bit. And first users were burned by the Heartbleed attack. Then even three years is not a long time in terms of updates to IT infrastructure. This excludes RHEL5 (Redhat) which is heavily used and still supported for years. And with larger installations you do not simple upgrade a part because there are lots of unexpected things which might break or need to be reconfigured. Combine this with a shortage of qualified IT personal and you can see why you even still finds lot of Windows XP installations and companies rather pay for extended support. Commented Apr 10, 2015 at 3:13
  • For Java, also of some importance server-side, Java7 in mid-2011 added 1.1 and 1.2. And also an ECC provider, enabling ECDHE (and other ECDH). Commented Nov 21, 2015 at 4:53

There is no security benefit in disabling TLS1.1 and 1.2 in favor of 1. And there is actually no compatibility benefit either*.

The reasons why some sites only support TLS1 is, that the software and/or configuration is simply too old.

Just stating the obvious, disabling all protocol versions older than TLSv1.2 is a security benefit as all of them have known weaknesses compared to 1.2.

* On server side. It is unfortunately a bit different for clients which have to talk to very old and broken servers. They might not want to offer TLS1.1 or TLS1.2 for compatibility reasons. Or actually if they offer it, they might want to retry without.

  • There is BTW a performance benefit for some clients like Java, if TLS1.2 is enabled it will offer AES-GCM and some server pick that. This is dog slow compared to AES-CBC. This was only recently improved in Java 9, but still not up to the speed of CBC (and we are talking here way below 10mbits line speed)
    – eckes
    Commented Sep 2, 2016 at 21:42

An update for all those who might discover this question. It's now 2017, and TLS1.0 is deprecated and should not be used.

Indeed, if you have any form of credit card interactions on your site (even if the credit card data is posted directly to the payment gateway site, and does not touch your server) then, in order to comply with PCI/DSS rules, TLS1.0 has to be disabled on the server, effectively cutting off older browsers.

And by 'older browsers' we are talking anything up to IE10 on Windows 7!

Edit: As pointed out below, TLS1.0 is still officially allowed on existing sites until the end of June 2018. However, this does not seem to filtered down to all the testing services, so you may find even existing sites are required to stop supporting TLS1.0 sooner than expected.

  • 2
    TLS 1.0 is deprecating and should not be used for new projects, but PCI/DSS still allows it until June 2018 (see this question). Commented Jul 24, 2017 at 12:00
  • @WhiteWinterWolf - Interesting. The ASV we use (Lloyds Bank Card Net) failed us recently for still supporting TLS1.0, for an existing web site. I've already removed TLS1.0, so I won't be going back to them to argue about keeping it. For clients that don't support TLS1.2, which we estimate to be around 1% of our visitors, I've written same JavaScript that does a jquery Ajax call to a secure page on the site, and uses the 'onerror' callback, to display a banner recommending they upgrade. Of course, if they land on a HTTPS page, they just get the in browser error.
    – cyberspy
    Commented Jul 31, 2017 at 8:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .