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.
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.)
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.
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?
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.
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.
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.
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.
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.
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.