On August 1st, we finished up a 6 week transition process which eliminated the last non-forward-secret cipher supported by our TLS termination, which was bare AES128-SHA. This change guarantees that all TLS connections to Wikipedia and its sister projects use cipher suites that provide forward secrecy. Wikipedia is the first major high-traffic site to take this step.

From now on, it won’t be possible for an attacker to decrypt the information sent between your browser and Wikipedia even if the private key of Wikipedia's TLS certificate gets compromised.

How’s that even possible?

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances your session keys will not be compromised even if the private key of the server is compromised. -- From https://en.wikipedia.org/wiki/Forward_secrecy

When using forward secret cipher suites, the private key of the server’s certificate is only used to authenticate the server's identity to the client. A unique session encryption key is negotiated without any dependency on the certificate private key. This session key will be used to encrypt the information exchanged between the server and the browser. The session key is exchanged using one of several variants on the basic Diffie-Hellman key exchange algorithm.

Why is this important?

Forward-secret ciphers are nothing new; they're commonly deployed as the first preference in modern browsers and servers. What's new here is we've removed all fallback compatibility for ciphers which are not forward secret, so that there is no possibility of connecting to us without forward secrecy. This also categorically prevents any current or future downgrade attacks back to non-forward-secret operation against modern clients connecting to us.

While researching AES128-SHA usage on our sites, we discovered that sometimes even up-to-date browsers were negotiating the legacy non-forward-secret AES128-SHA cipher suite with us, even though it was the last resort in our cipher preference list. This can only be explained by the presence of a layer 7 TLS proxy acting as a man-in-the-middle and downgrading modern clients' connection security. These kind of devices are usually corporate TLS "security" devices deployed in some networks to perform Deep Packet Inspection (DPI). We suspect these boxes negotiate poor cipher choices like AES128-SHA for a few different reasons:

• The box is simply outdated or un-upgraded and doesn’t support newer cipher suites
• Keeping the connections non-forward-secret makes monitoring and logging easier
• Avoiding forward-secret key exchanges makes their hardware scale better

By dropping support for non-forward-secret ciphers, we're effectively requiring the vendors and users of these boxes to support at least basic forward secrecy if their clients are to continue accessing Wikipedia, which will hopefully help improve TLS security levels for all users of modern clients behind such devices.

How’s Wikipedia doing compared to the other big players?

According to Alexa and Qualys SSL labs (data gathered on July 31st 2018), Wikipedia is the only site in Alexa's top 50 (where we're currently #5!) exclusively offering forward secret ciphers.

We hope our move will encourage other sites to follow suit and drop their non-forward-secret ciphers as well. If we can do it with the huge and diverse global audience Wikipedia has, almost any other site should be able to as well.

What’s next?

Our next major goal in this space is deprecating support for TLS 1.0 and TLS 1.1.

TLS 1.0 has been marked as non-secure by PCI-DSS on June 30th, making it mandatory to disable for PCI-DSS compliance. During July we’ve seen a pretty important TLS 1.0 usage drop-out on Wikimedia sites from 1.72% to 1.20% (consider that at Wikipedia scale, 1% represents ~1k requests per second on average). Since Wikipedia itself doesn't process payments, the PCI-DSS rules don't directly apply to us. Mostly, we're waiting for that 1.20% to naturally fall to a more palatable number, pressured by commercial sites' lack of support pushing users to upgrade. We're hoping we'll be able to get this going by the end of 2018.

After deprecating TLS 1.0 and 1.1, we will likely be able to stop providing support for the remaining weaker ciphers: those using CBC as block cipher mode of operation and any cipher suites using weak message authentication algorithms like SHA1. These may take longer to eliminate, as there's a non-negligible population of outdated Safari installations which still will rely on them at present.

After all of the above, we'll be left with a fairly clean and secure configuration offering only TLS 1.2 (and TLS 1.3 in the near future), using only ciphersuites which offer both forward secrecy and AEAD.

PS - If you'd like to work on fun problems with us, our SRE team is hiring!