Thread:User talk:Ryan lane/TLS on Wikipedia

In reference to https://wikitech.wikimedia.org/wiki/Https

1. Is this information accurate, and

2. Is it the same for Wikipedia?

3. Based on information I could obtain via probing, you appear to be using nginx with openSSL 1.0.1 as load balancing proxy for another server. The proxy connects to the server over plain HTTP. Is this correct? Until I know this, I can't accurately make suggestions on what to change in your configuration files.

First impression issues:

1. Server does not enforce cipher suite order and lets the client choose.

2. Performance first configuration, offers next to no security.

3. The server certificates used are valid for too long a stretch of time, considering the "weak" cryptographic primitives they rely on.

4. Plain HTTP is the default.

I would propose you make the following changes to your infrastructure (most important first):

1. Sniff the crawlers for the most popular search engines, inform them of such a change and permanently redirect all URLs they access to a TLS secured one. This would have a significant number of users visit the site moderately securely very quickly.

2. You enforce the cipher suite order and change it to something like this:



It includes all selectable options as of openSSL 1.0.1e, sorted by their arithmetic safety rating (assuming < 4096-bit RSA, < ~300-bit ECDSA and popular browser capability), except those permanently excluded via the parameters at the end. To disable a cipher suite, put a dash after the colon in front of it. I would recommend, unless you still have a large set of users connecting with IE6 on Windows XP SP2 and prior, that you remove all 3DES cipher suites as well.

3. Get new SSL certificates using at least 2048-bit RSA and ~240-bit elliptic curve keys and sha-256 authentication. Make sure each individual server has its own public key pairs. Include each servers own unique host name first in the list of subject alternative names of the public certificate that is transmitted with each TLS connection. Make sure your certificates expire before they could be arithmetically broken (That's sometime late 2014 for 2048-bit RSA). Remove and revoke all current certificates. Optional (compatibility): Create and have certificates signed which all have the same public key for each server but all FQDNs the server serves in the subject canonical name field and add them to the server configuration before the wildcard certificate.

4. Make sure all certificates and their public keys are mentioned in order of preference in the server configuration.

5. Enable Strict Transport Security headers for all HTTPS connections

6. Disable SSL3.0

7. Enable OCSP stapling

8.

Will add more later, may revise text, in the meantime, this may be a good read: https://www.ssllabs.com/projects/best-practices/ even though it gets a few key things wrong and refrains from mentioning others to keep the document short. I've got to do something else now.