HTTPS/3DES Deprecation

From Wikitech
This page contains historical information. It may be outdated or unreliable.

Overview

The Wikimedia Foundation has deprecated support for the 3DES cipher in our standard TLS termination software. We've been occasionally warning the users of this cipher for about a year now through technical means. The active deprecation and removal cycle is a three month process running from 17 August to 17 November, of 2017. After that time, no users will be able to connect at all using this specific cryptographic cipher.

Impact

The primary user agent impacted by this change will be Internet Explorer versions 7 and 8 running on the Windows XP operating system. While 3DES is the worst cipher we have continued to support in recent years, it is the best and only compatible cipher which remains for that browser. While IE8/XP is the cause of the overwhelming majority of 3DES usage, there is also a long tail of other statistically-insignificant user agents of similar age and security level which will be impacted as well.

Process

Manual view of current "warning message" page: https://en.wikipedia.org/sec-warning . This will call out the timeline of the process and offer links for the common case where IE8/XP users need to install Firefox 52 ESR as a replacement UA.

  • Aug 2016 - Started limited page replacement campaign. ~1% random probability of pageviews using 3DES replaced with warning message about crypto deprecation and link to HTTPS/Browser_Recommendations with no specific dates.
  • Aug 7, 2017 - Announcement in Tech News: https://meta.wikimedia.org/wiki/Tech/News/2017/32
  • Aug 17, 2017 - Warning text and various other related texts updated with specific dates and better messaging (and this page created!)
  • Aug 17, 2017 - Oct 17, 2017 - Percentage of 3DES pageviews replaced with warning message gradually increases from ~5% to ~30%. This means users with 3DES user agents will by the end of this period be seeing a warning message replace their pageview about 1/3 of the time. As this is completely random, they may occasionally have to reload multiple times to get past this by the end.
  • Oct 17, 2017 - Percentage raised to 100%. Actual pageviews no longer possible, but users can still connect to our sites and observe the warning message.
  • Nov 17, 2017 - Technical support for 3DES stops at the protocol level. These user agents will no longer be able to connect to our sites directly at all.

Technical Rationale

  • Proactivity in general
    • TLS has a history of past protocol and cipher breaches, and it's virtually inevitable that 3DES will suffer such an event in the future if it's not removed from service first.
    • We'd rather be in the position of removing this weak, minority cipher from service smoothly before it completely fails. The alternative is we wait for real harm to occur to users (and the major announcement that follows), and then are forced to rip it out in a very sudden and reactive way.
  • 3DES Weakness
    • 3DES is the last remaining 64-bit block cipher we support. 64-bit block ciphers are cryptographically weak in general.
    • The SWEET32 attack was announced last year. While this approach (Birthday Attacks) was always a known approach, especially for 64-bit block ciphers, the SWEET32 announcement gave us a pragmatic demonstration of just how weak such things are becoming. The attack is practical when large amounts of data are transferred, and these amounts are now within reasonable range for attack attempts at modern client link speeds, especially given TLS session reuse lifetimes necessary for reasonable connection performance in general.
    • The remaining 3DES cipher we support is specifically DES-CBC3-SHA. This is one of only two non-forward-secret ciphers that remain supported (the other being, for now, AES128-SHA), and eventually achieving 100% forward secrecy is an important goal that helps increase long term security for all users. There are forward-secret variants of 3DES available in the TLS protocol, but in practice they are not useful for solving this part of the problem, as the User Agents in question (e.g. IE8/XP) do not support those variants.
  • Statistical Relevance Waning
    • We track statistics on TLS cipher choices at https://grafana.wikimedia.org/dashboard/db/tls-ciphers . [Broken Link T211982]
    • 3DES usage has consistently dropped in recent years. About a year ago 3DES was used for ~0.18% of all requests, and more-recently that number has been closer to ~0.11%.
    • However, the rate of the decline has slowed, and appears to be reaching a natural floor around the ~0.10% mark. This means we're probably nearing the end of the time we can rely on natural decline moving this issue forward, and it's time to start forcing the issue in order to finish it off.
    • While ~1/1000 requests is still a significant raw number on a large site like Wikipedia, we're past the point where we don't want to hold the security of the other 999 hostage to the potential security issues caused by the few. So long as we continue to support this cipher, there will be risks that users of better User Agents can be downgraded to it silently in targeted attacks, through other protocol weaknesses.
  • Client Platform Weakness
    • The overwhelming bulk of requests using 3DES, as mentioned above, come from IE8/XP.
    • IE8/XP is a completely broken platform from a security perspective, and has been for a long time now. The vendor abandoned it for security updates back in 2014, and many practical attacks against this platform exist.
    • Therefore, users of IE8/XP essentially cannot trust their own computer, and similarly sites like Wikipedia cannot trust that the user agent is not compromised by a third party.
  • Mozilla Firefox Support Lifecycle
    • Our recommended fix for users stuck on Windows XP computers is to install Mozilla's Firefox as an alternative browser to replace Internet Explorer. This is the only major, secure browser which continues to support Windows XP at this time.
    • However, Firefox has already made their last major release for this platform, which is Firefox 52 ESR. Future versions will not support XP.
    • Mozilla's product lifecycle information calls out mid-2018 as when they'll drop support for this final XP-supporting release.
    • After support ends, an already-installed copy of FF 52 ESR will continue to function, but will no longer receive support or updates from Mozilla.
    • After support ends, it may eventually become increasingly hard to link users to install a backdated release as an alternative to IE, and it may be harder for them to get any support from the Mozilla Foundation to fix any corner-case issues with these installations that may bite specific users.
    • All of these things in mind, it's prudent on our end to force our users which are stuck on XP to make the transition to Firefox as soon as possible, before that supported period ends. Afterwards we won't be able to offer them any great solutions.
  • The end is coming regardless
    • The PCI standards, which apply to most sites which allow credit card payment transactions, require the removal of TLSv1.0 support by server operators by mid-2018 as well. This also (for slightly different reasons than 3DES) denies access to IE8/XP, and thus will make it non-functional for vast swaths of the commercial Internet.
    • NIST is currently in the process of revising and updating their "Special Publication 800-67 - Recommendation for Triple Data Encryption Algorithm (TDEA) Block Cipher" (which is their name for 3DES). The current draft states:

    The security of TDEA is affected by the number of blocks processed with one key bundle. One key bundle shall not be used to apply cryptographic protection (e.g., encrypt) more than 2^20 64-bit data blocks.

    This is a response to birthday attack advances such as SWEET32. In practice for TLS usage the recommendation means a single session key (which can potentially be re-used across multiple TLS sessions) cannot be used to encrypt more than 8 Mebibytes of data. If one follows this security guidance, even a single pageview of a larger Wikipedia article would violate these security limits and shouldn't be served to the user at all. The connection would need to re-key for security reasons before the article was completely transferred, and in practice there is no way to re-key these sessions in the midst of a single HTTP transfer.
    • The current stable release of OpenSSL (the server-side cryptography library used by most sites on the Internet) disables 3DES by default at compile-time. It can only be re-enabled through a custom build (which is what we're doing today at Wikimedia, until we end support in November). Future releases of this and other libraries are likely to lack support completely, even in custom builds.
    • The upcoming revision of the TLS standards (TLSv1.3) removes 3DES completely as an option (along with many other weak choices).
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=HTTPS/3DES_Deprecation&oldid=2046047"