44

The PCI Data Security Standard 3.1 recommends disabling "early TLS" along with SSL:

SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.

The Migrating from SSL and Early TLS supplement states:

The best response is to disable SSL entirely and migrate to a more modern encryption protocol, which at the time of publication is a minimum of TLS v1.1, although entities are strongly encouraged to consider TLS v1.2.

I have a few questions regarding the deprecation of TLS 1.0:

  • What is the reason for this recommendation? Are there known vulnerabilities with the TLS 1.0 protocol? (I'm aware that some faulty TLS implementations are vulnerable to POODLE but a SSL Labs scan indicated that my site was not vulnerable.)
  • Is it necessary/desirable to apply this standard to web applications using HTTPS that are not handling credit card information?
  • Is disabling TLS 1.0 and restricting to TLS 1.1 or 1.2 on public-facing websites using HTTPS likely to break browser compatibility for a significant proportion of users?
augurar
  • 583
  • 1
  • 4
  • 7
  • 1
    On the procedural part of bullet 2: DSS applies to 'components included in or connected to the cardholder data environment' which usually includes everything in the same network segment or 'zone'. If an app or system does not 'store, process, or transmit cardholder data' _and_ is isolated from things that do, DSS is not required. It is a fairly thorough set of mostly good practices, and you may voluntarily use it or parts of it for other things. – dave_thompson_085 Feb 16 '18 at 04:03
  • 1
    Given the time-sensitive nature of the context, would it be permissible to re-ask this question? – Shadur May 04 '18 at 08:11
  • @Shadur Seems reasonable, but you might want to ask about it on [meta](https://security.meta.stackexchange.com/). – augurar May 04 '18 at 17:40

3 Answers3

53

TLS 1.0 when properly configured has no known security vulnerabilities. Newer protocols are better designed and better address the potential for new vulnerabilities. So that's why

I wouldn't personally recommend disabling TLS 1.0, primarily because IE 7-10 don't support TLS 1.1 out of the box. In January 2020, IE10 has gone EOL, so I expect it's likely now a good idea to disable TLS 1.0 since there's likely little/no traffic from such an old browser. If you look carefully at the support matrix at: https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers you'll see that TLS 1.1 is disabled by default on everything but IE 11.

Most people have a significant amount of traffic on these browsers, and your website suddenly not working would pose a significant business impact. Many people here will advocate a single minded approach of "Security above all else", and tell you to strongly advocate for disabling TLS 1.0. I'm of the belief that security needs to be balanced with business needs, and it's the job of the security professional to understand both the security side, and the impact of changes. As of 2020, the general principle here still applies, but the tradeoffs have moved towards disabling TLS1.0 in most circumstances. There may still be some special circumstances of old, embedded devices where you might be able to justify keeping TLS1.0 enabled.

In 2020, there's little reason to keep TLS1.0 around, at least for browsers as the client. You obviously need to test the impact of this on the stock browser config, and understand how much business you may or may not lose from this change.

Steve Sether
  • 21,530
  • 8
  • 50
  • 76
  • 1
    Pragmatic response. If you have counter measures in place you could still be PCI compliant, given a reasonable business need. – Richard Nov 23 '15 at 23:59
  • @Richard So essentially PCI just requires a justification, and reasonable accommodations for breaking the official rules? – Steve Sether Nov 24 '15 at 14:19
  • 1
    Yes, you can have a 'compensating control', so if you have good reason and you can mitigate the risk the original requirement was addressing. It may be easier just to switch off the old protocol, but like you say you need to see how that will impact your business. A bit of info on how to do it here: https://pciguru.wordpress.com/2015/07/25/compensating-control-refresher/ – Richard Nov 24 '15 at 15:00
  • "Still, if you need to maintain PCI compliance, you may be forced to disable TLS 1.0." Can you provide a citation for this? – TylerH Feb 15 '18 at 15:07
  • 1
    @TylerH: the original SSC docs are linked in the question, although DSS 3.1 has since been superseded by 3.2 with no change to this requirement. Or just go to https://www.pcisecuritystandards.org/ and it's currently at the top center of the homepage. – dave_thompson_085 Feb 16 '18 at 03:51
15

I also recommend disabling TLS 1.0 if possible and supporting the most modern cryptography and cipher suites your web servers can handle.

  • TLS 1.0 is vulnerable in many implementations to a couple well-known attacks such as BEAST and POODLE. There's also some crypto issues in TLS 1.0, such as cryptograhpic initialization vectors (IV's) being predictable in some implementations as well. This is replaced in TLS 1.2 to protect against cipher block chaining (CBC) attacks.

  • Yes, as a best practice you want to support modern cryptography on all sites you publish over HTTPS, even if they aren't handling credit card or other personal information. You also want to disable cryptographic standards that are considered obsolete, deprecated and/or have known attacks against them. Furthermore, some browsers will start to alert if you're using TLS 1.0 (e.g. Chrome and its "obsolete cryptography" warning), so this best practice is being highly encouraged by the browsers, and is prominently viewable by the user.

  • Disabling TLS1.0 may certainly cause issues for some users with outdated browsers. However, they'd have to be significantly out of date..meaning not updated since 2013-2014 depending on the browser. The issue may be the most significant with Internet Explorer, which for a while disabled TLS. A full compatibility chart is available on Wikipedia. Comparing this matrix to your logs for HTTP_USER_AGENT headers should tell you how many visitors you'd expect to potentially have issues.

Herringbone Cat
  • 4,282
  • 15
  • 19
  • 1
    Regarding your second bullet point -- note that this question is specifically about disabling TLS 1.0; my servers already have TLS 1.1 and 1.2 enabled for clients that support them. – augurar Nov 23 '15 at 20:08
  • @augurar Duly noted, I've edited the answer to indicate that disabling deprecated ciphers is also a best practice. – Herringbone Cat Nov 23 '15 at 20:11
  • 1
    Only a few nonconforming implementations of 1.0 were vulnerable to Poodle (socalled "Poodle Again") as Q correctly stated. *All* 1.0 implementations necessarily use exposed IV except for first message, but BEAST turned out to be no danger because of the scarcity of applicable 0days on clients, plus practically all stacks now use record splitting (1/n) that totally blocks it. And the randomized-IV fix is in 1.1, not just 1.2. – dave_thompson_085 Nov 24 '15 at 00:57
0
Community
  • 1
DarkLighting
  • 1,513
  • 11
  • 16
  • 4
    The first two are good things to remember but not answers to the question. You can (and definitely should) disable EXPORT (and also single-DES, which isn't technically export but is also too weak) while still running 1.0. CRIME is independent of protocol version. – dave_thompson_085 Nov 24 '15 at 01:00