The Web is World-Wide, or who still needs RC4? | Hacker News Reader

The Web is World-Wide, or who still needs RC4?

blog.cloudflare.com

54 pointsjgrahamc22 comments

Youtube requires RC4

      sslscan r18---sn-nx57yn7r.googlevideo.com
                       _
               ___ ___| |___  ___ __ _ _ __
              / __/ __| / __|/ __/ _` | '_ \
              \__ \__ \ \__ \ (_| (_| | | | |
              |___/___/_|___/\___\__,_|_| |_|
    
                      Version 1.8.0
                 http://www.titania.co.uk
            Copyright Ian Ventura-Whiting 2009
    
    Testing SSL server r18---sn-nx57yn7r.googlevideo.com on port 443
    
      Supported Server Cipher(s):
        Rejected  N/A              SSLv2  168 bits  DES-CBC3-MD5
        Rejected  N/A              SSLv2  56 bits   DES-CBC-MD5
        Rejected  N/A              SSLv2  40 bits   EXP-RC2-CBC-MD5
        Rejected  N/A              SSLv2  128 bits  RC2-CBC-MD5
        Rejected  N/A              SSLv2  40 bits   EXP-RC4-MD5
        Rejected  N/A              SSLv2  128 bits  RC4-MD5
        Rejected  N/A              SSLv3  128 bits  ADH-SEED-SHA
        Rejected  N/A              SSLv3  128 bits  DHE-RSA-SEED-SHA
        Rejected  N/A              SSLv3  128 bits  DHE-DSS-SEED-SHA
        Rejected  N/A              SSLv3  128 bits  SEED-SHA
        Rejected  N/A              SSLv3  256 bits  ADH-AES256-SHA
        Rejected  N/A              SSLv3  256 bits  DHE-RSA-AES256-SHA
        Rejected  N/A              SSLv3  256 bits  DHE-DSS-AES256-SHA
        Rejected  N/A              SSLv3  256 bits  AES256-SHA
        Rejected  N/A              SSLv3  128 bits  ADH-AES128-SHA
        Rejected  N/A              SSLv3  128 bits  DHE-RSA-AES128-SHA
        Rejected  N/A              SSLv3  128 bits  DHE-DSS-AES128-SHA
        Rejected  N/A              SSLv3  128 bits  AES128-SHA
        Rejected  N/A              SSLv3  168 bits  ADH-DES-CBC3-SHA
        Rejected  N/A              SSLv3  56 bits   ADH-DES-CBC-SHA
        Rejected  N/A              SSLv3  40 bits   EXP-ADH-DES-CBC-SHA
        Rejected  N/A              SSLv3  128 bits  ADH-RC4-MD5
        Rejected  N/A              SSLv3  40 bits   EXP-ADH-RC4-MD5
        Rejected  N/A              SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
        Rejected  N/A              SSLv3  56 bits   EDH-RSA-DES-CBC-SHA
        Rejected  N/A              SSLv3  40 bits   EXP-EDH-RSA-DES-CBC-SHA
        Rejected  N/A              SSLv3  168 bits  EDH-DSS-DES-CBC3-SHA
        Rejected  N/A              SSLv3  56 bits   EDH-DSS-DES-CBC-SHA
        Rejected  N/A              SSLv3  40 bits   EXP-EDH-DSS-DES-CBC-SHA
        Rejected  N/A              SSLv3  168 bits  DES-CBC3-SHA
        Rejected  N/A              SSLv3  56 bits   DES-CBC-SHA
        Rejected  N/A              SSLv3  40 bits   EXP-DES-CBC-SHA
        Rejected  N/A              SSLv3  40 bits   EXP-RC2-CBC-MD5
        Accepted  SSLv3  128 bits  RC4-SHA
        Rejected  N/A              SSLv3  128 bits  RC4-MD5
        Rejected  N/A              SSLv3  40 bits   EXP-RC4-MD5
        Rejected  N/A              SSLv3  0 bits    NULL-SHA
        Rejected  N/A              SSLv3  0 bits    NULL-MD5
        Rejected  N/A              TLSv1  128 bits  ADH-SEED-SHA
        Rejected  N/A              TLSv1  128 bits  DHE-RSA-SEED-SHA
        Rejected  N/A              TLSv1  128 bits  DHE-DSS-SEED-SHA
        Rejected  N/A              TLSv1  128 bits  SEED-SHA
        Rejected  N/A              TLSv1  256 bits  ADH-AES256-SHA
        Rejected  N/A              TLSv1  256 bits  DHE-RSA-AES256-SHA
        Rejected  N/A              TLSv1  256 bits  DHE-DSS-AES256-SHA
        Rejected  N/A              TLSv1  256 bits  AES256-SHA
        Rejected  N/A              TLSv1  128 bits  ADH-AES128-SHA
        Rejected  N/A              TLSv1  128 bits  DHE-RSA-AES128-SHA
        Rejected  N/A              TLSv1  128 bits  DHE-DSS-AES128-SHA
        Rejected  N/A              TLSv1  128 bits  AES128-SHA
        Rejected  N/A              TLSv1  168 bits  ADH-DES-CBC3-SHA
        Rejected  N/A              TLSv1  56 bits   ADH-DES-CBC-SHA
        Rejected  N/A              TLSv1  40 bits   EXP-ADH-DES-CBC-SHA
        Rejected  N/A              TLSv1  128 bits  ADH-RC4-MD5
        Rejected  N/A              TLSv1  40 bits   EXP-ADH-RC4-MD5
        Rejected  N/A              TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
        Rejected  N/A              TLSv1  56 bits   EDH-RSA-DES-CBC-SHA
        Rejected  N/A              TLSv1  40 bits   EXP-EDH-RSA-DES-CBC-SHA
        Rejected  N/A              TLSv1  168 bits  EDH-DSS-DES-CBC3-SHA
        Rejected  N/A              TLSv1  56 bits   EDH-DSS-DES-CBC-SHA
        Rejected  N/A              TLSv1  40 bits   EXP-EDH-DSS-DES-CBC-SHA
        Rejected  N/A              TLSv1  168 bits  DES-CBC3-SHA
        Rejected  N/A              TLSv1  56 bits   DES-CBC-SHA
        Rejected  N/A              TLSv1  40 bits   EXP-DES-CBC-SHA
        Rejected  N/A              TLSv1  40 bits   EXP-RC2-CBC-MD5
        Accepted  TLSv1  128 bits  RC4-SHA
        Rejected  N/A              TLSv1  128 bits  RC4-MD5
        Rejected  N/A              TLSv1  40 bits   EXP-RC4-MD5
        Rejected  N/A              TLSv1  0 bits    NULL-SHA
        Rejected  N/A              TLSv1  0 bits    NULL-MD5
    
      Prefered Server Cipher(s):
        SSLv3  128 bits  RC4-SHA
        TLSv1  128 bits  RC4-SHA
    
      SSL Certificate:
        Version: 2

This needs more attention. Its total bullshit. I can't watch youtube videos in Firefox 29 because of this.. Well with RC4 disabled. Currently I use Opera for my youtube watching, and firefox for my general browsing. Its a hassle and should be fixed. RC4 is broken [citation not given because shouldn't be needed], its been broken for a while and isn't gonna fix itself any time soon.

For what it's worth, I have the same issue and have been watching Youtube videos in FF by falling back to the HTTP version. It's not as if the TLS was offering any privacy anyway.

THIS.

Im fine with legacy RC4 when you need to support 10 year old phones or wii, but its ridiculous when YT, or Occulus requires broken crypto. Occulus uses RC4 on their order page, meaning personal data and financial information.

https://developer.oculusvr.com/forums/viewtopic.php?f=34&t=5...

support.oculusvr.com has all modern crypto enabled, its like they specifically crippled financial side of website.

Does NSA send national security letters demanding downgrade to RC4?

For future reference the `--no-failed` is a good idea when you want to paste the output of sslscan. Especially if you update your sslscan. I ran the same command as you and sslscan listed 150+ additional cipher combinations that were failed/rejected.

Thanks for the report. We, Google, are currently working to add support for other ciphers. (I was going to file a bug, until I noticed there was already one with work underway).

Assuming you actually represent google, can you link to the bug, or paste bin if your bug tracker isn't publicly accessible?

I'm curious to know what was the basis of this configuration decision. It seems like someone went out of their way to hamstring your encryption. Possibly someone benchmarked every combination and disabled all but the fastest. Wouldn't something like this go through a security review before hitting prod?

Sorry, this is an internal bug tracker, so I am not allowed to share any detail.

I tried to find a normal channel to report this and came up empty. In the future, how does on alert google to issues like this?

In that case, a Youtube issue, go to https://www.youtube.com/t/contact_us, click "Current Site Issues", and follow the instructions.

I assume they do this for speed? When you are running that many videos you could save real money by making encryption cheaper and pack more onto each server. Is there any other justification for this?

Speed is not a good reason. While RC4 is great for weak chips, like microcontrollers and such, it is actually not that fast in modern hardware, needing at least 4 cycles per byte. The fastest combination of RC4 and MD5 in OpenSSL manages 6 cycles per byte [1].

With AES-NI, AES128-GCM runs at roughly 1 cycle per byte. Without AES-NI, the recent Chacha-Poly1305 ciphersuite Google has been experimenting also runs at between 1 and 2 cycles per byte.

[1] https://github.com/openssl/openssl/blob/master/crypto/rc4/as...

Many sites started requiring it to mitigate BEAST, CloudFlare included.

Wonderful and fascinating analysis. Thanks for the data.

You can see why SSL proxies would prefer a lighter weight protocol, hijacking all that traffic is taxing! On the other hand, if you're in the middle for presumably legitimate reasons, you have a responsibility to protect those connections. On the other hand, a malicious man-in-the-middle would want to go undetected, and probably does a better job of passing along the same protocol the client is using. It's time to replace those ancient proxies, and perhaps consider not restricting your users freedoms. A win-win.

Jeff Jarmoc had a great talk about this at BlackHat Europe:

http://www.secureworks.com/cyber-threat-intelligence/threats... https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-S...

He described the risk of outsourcing cryptographic security to a proxy -- though he was more focused on the fact that the proxy might not be as cautious or as correct about validating certs as your client, rather than that the proxy might have a different ciphersuite policy than your client. But he does explicitly mention this risk, including the idea that the proxy may be using a weaker ciphersuite. (The example he gives is PFS, where your client and the server might both support PFS ciphersuites, but the proxy might not, so you don't actually get PFS.)

Yep. Things like Bluecoat were vulnerable to reverse-heartbleed, even if the servers/clients behind them weren't.

Don't know about the rest of you, but the most secure cipher I can support on older combinations of Apache and OpenSSL is RC4. I'm (slowly) replacing these old installs with Apache 2.4 and OpenSSL 1.0.1, which gives me TLSv1.2 and newer cipher suites. I'd imagine that many web servers and not a few browsers are stuck at TLSv1.0, where RC4 is more secure than other cipher suites because of BEAST.

Verisign still uses RC4 in its certificates. While most of the trusted certificates have moved to SHA-1 and SHA-2, Verisign still uses RC4 in some places.

You're confusing encryption algorithms (RC4) and hash algorithms (SHA-1 and SHA-2). Certificates do not use an encryption algorithm nor do they influence your choice of encryption algorithm.

check the security certificate here, I might be wrong about the exact nature, but the last I heard, MD5 and RC4 in certificates were bad.

https://www.unionbankonline.co.in/

I don't see MD5 anywhere in that certificate. I think that you are confusing the ciphersuite (which is negotiated dynamically between the client and the server on each connection, and is actually used to directly protect and authenticate the content of the communication) with the certificate (which is issued infrequently -- typically once per year or once every other year -- by a certificate authority and used to authenticate the server's public key, which is one prerequisite for secure session negotiation).

The signature algorithm in the certificate itself is sha1WithRSAEncryption (try exporting the cert and running "openssl x509 -in their_cert.pem -text -noout" for a summary of the content). I also don't see RC4 anywhere in the cert.

It is true that the web server is using RC4 to protect the TLS connections that it negotiates (probably inadvisedly!), and that MD5 is also used in its negotiated ciphersuite, but the use of these algorithms isn't specified, required, recommended, or assumed anywhere in the digital certificate that the server is presenting to authenticate the connection. Rather, the choice of RC4 (and MD5) is made dynamically during the ciphersuite negotiation between the client and server on each connection, presumably based on the (somewhat obsolete) server defaults that the bank has chosen.

I agree with the previous commenter that RC4 can't be specified (or used) in certificates, though MD5 can be used as part a signature method within the certificate, but happens not to be in your example.

Ah that clears up a few things for me. Thanks.

Reply on news.ycombinator.com