Hacker News Reader

Comment by sehrope | Hacker News Reader

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

View on HN

There 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.

Presumably 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.

Or 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.

They clearly mention this goal in their blog post:

http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-...

Wikimedia seems to make a habit out of "considering" things for a long time before actually enabling them. Enabling forward secrecy is relatively straightforward.

Yes. 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.

Traffic analysis is certainly an orthogonal problem to decryption of the ciphertext here. There's no reason to wait on one for the other.

At the scale of Wikimedia nothing is straightforward. Not even relatively.

This. We're talking about the fifth most popular site on the Web, operating on a budget smaller than my department at work.

Here'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-...

Great, 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.

Reply on news.ycombinator.com