4 ms·
They should switch to a better cipher suite to enable PFS[1] (ex: ECDHE-RSA-AES128-GCM-SHA256). Right now they're using RC4-SHA: $ echo | openssl s_client
by sehrope 13y ago
They should switch to a better cipher suite to enable PFS[1] (ex: ECDHE-RSA-AES128-GCM-SHA256). Right now they're using RC4-SHA:
$ echo | openssl s_client -debug -connect en.wikipedia.org:443 | grep "Cipher is" -A 4
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
[1]: http://en.wikipedia.org/wiki/Perfect_forward_secrecy http://en.wikipedia.org/wiki/Perfect_forward_secrecy
- semenko 13y agoThey clearly mention this goal in their blog post: http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/ http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-...
- kudu 13y agoWikimedia seems to make a habit out of "considering" things for a long time before actually enabling them. Enabling forward secrecy is relatively straightforward.
- Skalman 13y agoYes. However, if you do that, perhaps you're less motivated to find solutions to other, equally important problems with HTTPS. Enabling perfect forward secrecy is only useful if we also eliminate the threat of traffic analysis of HTTPS, which can be used to detect a user’s browsing activity, even when using HTTPS.
- mpyne 13y agoTraffic analysis is certainly an orthogonal problem to decryption of the ciphertext here. There's no reason to wait on one for the other.
- Sujan 13y agoAt the scale of Wikimedia nothing is straightforward. Not even relatively.
- davidgerard 13y agoThis. We're talking about the fifth most popular site on the Web, operating on a budget smaller than my department at work.
- 1qaz2wsx3edc 13y agoGreat, now let's also talk about auto-rotating keys. I think we should assume the NSA is cutting Fiber. My fear is they would sniff that for keys. If even one person fails to secure keys, we all lose. Hence why I think rotating keys are important.
- cowchase 13y agoHere's a sample nginx config that would prefer PFS over other key exchanges if the client supports it and is not vulnerable to the BEAST attack: ssl_ciphers EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5 Source: http://stackoverflow.com/questions/17308690/how-do-i-enable-perfect-forward-secrecy-by-default-on-apache#17463708 http://stackoverflow.com/questions/17308690/how-do-i-enable-...
- codex 13y agoThere are easier ways to reconstruct your HTTPS Wikipedia browsing habits than to crack HTTPS. Because Wikipedia's content is public, the NSA can crawl the site repeatedly with all common user agents, generating the number of HTTPS bytes needed to download any given Wikipedia page. Then, simply by looking at the patterns of bits sent over the wire, they can trivially reconstruct the likely pages a user was viewing. Wikipedia has not discussed any plans to mitigate traffic analysis; until they do so this whole exercise is futile, and I doubt Wikipedia will be able to obfuscate their site sufficiently to evade sophisticated traffic analysis.
- moocowduckquack 13y agoPresumably you could make it a single page site where the page and server act like number stations so that the page always uses a fixed bandwidth on a tick, some of which is data.
- siddboots 13y agoOr you could just insert a random payload into the served content. I imagine that you would only need to add a small amount of variation to completely thwart the type of analysis that codex described.