10

Reading different articles, mentioning this one, for the sake of this question on old TLS topic.

Quoting part of the article:

30 June 2018 is the deadline for disabling SSL/early TLS and implementing a more secure encryption protocol – TLS 1.1 or higher (TLS v1.2 is strongly encouraged) in order to meet the PCI Data Security Standard (PCI DSS) for safeguarding payment data.

I am thinking, if it is already the right time to disable TLS1.1 support on web servers?

To be specific on servers with highly sensitive data for instance.

Taking into account that most people won't be affected, because all the browsers (not counting systems as Vista or XP, nor old Android/Apple versions) already have support for TLS1.2 since a very long time ago.

So I say, I am up to disabling TLS1.1 on all my servers.

Most of you will probably argue, that such thing is sort of too aggressive, but why wait?

Improve this question
6
  • 6
    Do you have some data on your user base, which clients they are using? And what is the cost/effect if they can't access your service using their preferred client?
    – beetstra
    Commented Nov 26, 2017 at 12:41
  • 2
    In the end, I'm not sure this is a security question at all. Always go for the most secure. The option to stay at a lower, less secure version is not based on security metrics, but UX metrics ...
    – schroeder ♦
    Commented Nov 26, 2017 at 13:06
  • 3
    caniuse.com/#search=tls1.2 and caniuse.com/#search=tls1.1 and caniuse.com/#search=tls1.3
    – Tim
    Commented Nov 26, 2017 at 19:19
  • 1
    Not all servers handle card payments or comparably sensitive data. If you only need to help make mass surveillance impractical, probably even SSL3 RC4 with a selfsigned cert is good enough.
    – dave_thompson_085
    Commented Nov 27, 2017 at 1:25
  • You emphasize highly sensitive data, so optimize for security and disable TLS1.1. Only keep 1.1 if you are worried about some users not supporting this, just use ssllabs.com/ssltest to see what other sites do that your users may use. I looked at a governmental weather site, and at google.com, and found that these sites still enable TLS 1.0 and 1.1 (as of 10 january 2020)
    – Roland
    Commented Jan 10, 2020 at 14:56

2 Answers 2

Reset to default
15

The only reason to delay in saying goodbye is because of the potential impacts. In fact, the only reason to use any particular technology is that it does something for you and the cost/benefits are within your tolerances.

If you have quantified the impacts of cutting off an older technology and you are ok with it, then there is no argument... I'm not sure what security-based argument you were hoping to experience.

As for the security argument for 1.2, I'm not sure there even is one. Looking at the RFC, there is a lot of 'cleanup' and added modes, but no attack defence.

So, is it time? Probably not. There certainly no generally compelling reason to.

Improve this answer
1
  • users are part of any impact to an implementation
    – schroeder ♦
    Commented Nov 27, 2017 at 10:48
20

Let's put the question the other way: What do you gain by disabling TLS 1.1?

Security

You and your quote seem to be implying that you want to move to TLS 1.2 because it's more secure than TLS 1.1. That's not really the case.

TLS 1.2 did add new crypto, for example you can now use AES instead of 3DES, or ECDHE instead of DHE. At the moment, there are no known attacks against those ciphers so you can't directly say that it's for security. 1.2 also replaces MD5 and SHA1. That is a security improvement, but for something as short-lived as a TLS connection, it's unlikely to be a major weakness.

So while TLS 1.2 offers newer crypto algorithms, the old ones are still considered acceptable, so it's hard to make a straight security argument.

Performance

Because of the newer ciphers, you will get slightly less server load when using TLS 1.2. TLS 1.3 will offer improved performance at the protocol level as well. These by themselves may be reasons to switch, but it really has nothing to do with security.

Improve this answer
3
  • 3
    Mike: AES and ECDHE (and ECDH and ECDSA) work fine on 1.1 and 1.0, although due to timing ECC was not implemented on most stacks without/before implementing at least 1.1 and often 1.2. AES even worked on SSL3 back when SSL3 itself was acceptable. @Steffen: Suncle/OpenJDK 7 JSSE client disabled both 1.1 and 1.2 by default but could enable one or both; server enabled both by default. But 7 did not implement AEAD ciphers (only 8 did) so 1.2 only gave you new PRF, HMAC-with-SHA2, and SigAlgs (for certs and handshake). IBM Java uses its own cryptoproviders and may have differed.
    – dave_thompson_085
    Commented Nov 27, 2017 at 1:21
  • 1
    @dave_thompson_085 It's amazing how much I learn when I post an incorrect answer :P I'm not sure how to salvage my answer after that comment. Are you willing to edit, or post a better answer?
    – Mike Ounsworth
    Commented Nov 27, 2017 at 1:29
  • 1
    Let's also put the question this way: how many users/customers/revenues are you going to lose disabling TLS 1.1?
    – usr-local-ΕΨΗΕΛΩΝ
    Commented Nov 27, 2017 at 10:04

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