Thread:User talk:Ryan lane/TLS on Wikipedia/reply

Did you run an ssllabs test against en.wikipedia.org? Did you even run openssl s_client against en.wikipedia.org or check our certificates? To answer your questions:

On your first set of assertions:


 * 1) That's not correct. You can even see our nginx configuration in our puppet repo. All of Wikipedia's configuration is open to the public, feel free to check it out.
 * 2) That page hasn't been updated in a while, but the configuration isn't performance first. It's a mix of performance and security.
 * 3) What stretch of time would you recommend? It's a 4 year cert an is 2048 bit. There's no research that indicates this is too long of a period of time.

For your second set of assertions:


 * 1) Did you read the blog post? By setting rel=canonical to https you inform search engines that they should be indexing the https version of a page. At minimum google support this and that's roughly 45% of our referrer traffic (the lion's share of our referrer traffic is internal, most other search engines referrer traffic are miniscule). We will of course alert other search engines that don't support rel=canonical.
 * 2) TLS 1.2 is enabled, but I haven't added the GCM ciphers to the list yet. Was planning on doing this when I got back from Wikimania (I'm not going to make changes when the majority of the ops team isn't readily available). Otherwise, we don't plan on enabling perfect forward secrecy ciphers yet, as it's not very useful to have forward secrecy without first solving the problem of traffic analysis. Otherwise, the current cipher list we're using is a fairly standard configuration that protects against BEAST and offers a set of stronger ciphers for clients that ignore server preference.
 * 3) We already use 2048 certs. Just use openssl s_client to confirm.
 * 4) I have no idea what you mean by this, it makes no sense.
 * 5) We can't do this without blocking access to readers of Wikipedia in countries that block HTTPS. # This will cause compatibility issues for older clients. We support relatively old browsers (I think our general metric is any browser with >1% of our traffic). Can't do this.
 * 6) This is a performance setting, not a security setting. I didn't bother to mention performance things in the post, but we'll be doing a number of things to increase performance. OCSP stapling will be one along with some other likely things: SSL session tokens, SNI using domain specific certs for supported browsers and a unified cert for unsupported browsers, possible elimination of an intermediary CA, a distributed SSL cache across all SSL terminators, etc. etc.

Based on your twitter assertions, I was hoping for something terrifying ;).