YouTube requires the RC4 cipher for videos

[1]: https://twitter.com/ioerror/status/398059565947699200

"Support" for AES-GCM doesn't mean much if an RC4 ciphers is enabled and preferred by the server.

1. There are production servers that are still using RC4 only.

2. Consequently, clients can't disable RC4

3. Consequently, servers that prefer RC4 but offer better ciphersuites are insecure because they will negotiate RC4 even with better ciphers available. Client workarounds might be possible (involving multiple handshakes for rc4-only servers) but aren't implemented?

Disabling all RC4 ciphers breaks the Youtube player, unless your browser supports TLS_RSA_WITH_AES_128_GCM_SHA256, which isn't widely supported.

"The RC4 is fast" meme is true, because RC4 uses simple math operations like modulo and bitwise AND. [1]. CPUs have always done these operations fast. Other crypto algorithms used by SSL, like 3DES, were deliberately designed to be slow in software. [2].

However, modern Intel chips have dedicated instructions for perform AES, called AES-NI [3]. For these chips, an AES operation is not broken down into a series of opcodes the CPU executes. The CPU just does it. AES-NI is actually faster than RC4. [4]

We need to kill the RC4 is fast, everything else is slow myth. "TLS has exactly one performance problem: it is not used widely enough." [5]

1- http://en.wikipedia.org/wiki/RC4#Implementation

2- DES was designed around bit swapping, not byte swapping, which is super easy to do in hardware and much slower to do in software.

3- http://en.wikipedia.org/wiki/AES_instruction_set

4- http://zombe.es/post/4078724716/openssl-cipher-selection

5- https://istlsfastyet.com/

The last widely publicized attacks on RC4 used browsers and session cookies as targets. The attacks are practical --- in fact, they're among the simplest of the low-level cryptanalytic attacks (the flaws are statistical, and statistically trivial). Our implementations of the attacks clock in at hundreds, not thousands, of lines of code.

RC4 isn't a hair-on-fire problem and I wouldn't really worry too much about it at Youtube. But if you were operating a bank or a payment processor, I would tell you to make sure you weren't using RC4.

MD5 is broken in that you can generate collisions for it. But HMAC-MD5 is not broken; there is no theoretical attack on MD5 that breaks HMAC-MD5. It takes more than a simple collision to break HMAC.

The risk that systems that use HMAC-MD5 (and things like it) are taking is different from the risk that systems that use RC4 are taking. MD5 is broken, but HMAC-MD5 is actually (to the best of our knowledge, and with a very low margin) secure. RC4 is not actually secure in any scenario. But the cost/benefit of exploiting RC4 to recover the plaintext of a publicly-available streaming video is not great.

If I may quote GCHQ - a "surprising [...] cryptologic breakthrough" was obtained a few years ago from NSA.

We don't know for certain if that referred to an RC4 break specifically, but from context, I think that is the most probable candidate - a bulk cipher they've never used themselves, but widely-deployed internationally (at the time, and still to a large extent) on a huge number of websites largely because of advice to mitigate the BEAST attack (a tricky, active attack) not by switching to TLS 1.2, but by switching to a stream cipher designed in the late 80s for the 8086 that is showing its age poorly. That was probably not good advice.

What we do know for sure is that it's in a poor state; worse than any other cipher deployed in mainstream crypto. RC4 is Considered Harmful.

Go back and review what you've encrypted with RC4 previously, and evaluate if an eavesdropper could have recorded it and saved it for later when they do have a practical attack, and if so, if that's a problem - because in the state it's in, that is not a theoretical concern, because we know some Nation State Adversaries (cough) certainly do that en masse as general practice.

The IETF TLS Working Group have actually had a big discussion about this already - resulting in a live Internet-Draft not merely deprecating, but actively prohibiting RC4's use in TLS, which obtained strong-to-unanimous support in the Working Group and in my opinion will very probably be adopted as a WG document: https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-... - long story short, you MUST NOT use RC4 in TLS, don't even think about negotiating it, kill it with fire.

If you're still using it in anything else, consider this your I-told-you-so warning.

If you want a replacement, consider ECDHE-RSA-AES128-GCM-SHA256 or - if you want a modern stream cipher that's actually 256-bit secure yet faster in software than RC4 (unless you're on an 8086...) - ECDHE-RSA-CHACHA20-POLY1305: coming to an AEAD stream near you, and already with a draft implementation live in Chrome and on most of Google's properties thanks to agl's patches that more recently have become BoringSSL - but sadly not YouTube's video CDN yet, as the article notes.

I couldn't speak for OpenSSH, but I also think your information, or your software, may be out of date. SSHFP DNSSEC records, in particular, have had SHA256 on the Standards Track RFC for two years and change - https://tools.ietf.org/html/rfc6594

This isn't accurate.

There are two major attacks described in the recent literature on RC4.

The first targets single-byte biases in RC4. Simply: the distribution of key stream bytes at a given index is biased across all keys. By collecting a large number of ciphertext samples, you can match the bias in the ciphertext to the known biases in the key stream to recover plaintext.

These biases are only significant early in the key stream, say the first 256 bytes or so. Because they're only prevalent early in the key stream, you need to make a lot of connections.

This attack isn't a great fit if your target is a user's HTTP session, for two reasons. One is that you need to make a ton of connections, and there's not (to my knowledge) an easy way to force that from the attacker's perspective. Even if there were, you would incur quite a bit of overhead from all the TLS handshakes. The second and more important reason is that the HTTP session cookie just isn't going to show up in those first 256 bytes.

The second attack targets double-byte biases in the RC4 key stream. Again, these biases are known and measurable across all keys. By collecting a large number of ciphertext samples, you can perform analysis to recover plaintext. This is a little more complex because there is interdependence between bytes, but still not so tough. (Search for "hidden markov model" and "viterbi algorithm".)

The double-byte biases show up at regular intervals over any given key stream. This is important! It means the number of connections is irrelevant to plaintext recovery. What matters is just the amount of ciphertext you can collect.

This makes it a much better choice to attack HTTPS. We can collect all the ciphertext we need from one TLS session (or three or four or five, it doesn't matter). And we can also exert much finer control over where the HTTP cookies show up. As an attacker running JavaScript in a user's browser, you have this ability.

As the research notes, neither of the outlined attacks is practical today. But they're both knocking on the door. What if higher bandwidth or browser changes allow an attacker to take samples more quickly? What if someone refines the algorithms outlined in the paper? To the latter question, there are additional multi-byte biases (Mantin, 2005) they don't account for in their attack. It doesn't seem far-fetched to suppose these attacks could be improved.

So, is RC4 a game-over vulnerability in the context of TLS? Of course not. But conscientious site operators should look to migrate away from it as soon as practicality allows.

Did you mean to say OpenSSL there? OpenSSH uses PAM. PAM can use MD5 but OpenSSH has no control or oversight over that, the distribution you're using normally determines the hashing algorithm. You can also trivially reconfigure PAM to use something stronger if you so wish.

If you meant to say openSSL then your point is still quite confusing. MD5 is used in a few places around OpenSSL (e.g. digests, signatures, etc) none of which are weakened by MD5's weaknesses.

Can you clarify?

We don't have a requirement to encrypt Youtube video because Youtube videos are outside the scope of the policies we have that mandate encryption. Those policies prohibit the use of RC4 and because browsers don't allow varying the cipher support on a per-site basis, the result is nothing may use RC4. Because we don't have to encrypt the video and because Google doesn't support anything we can use we're left with the options of either finding a way to allow Youtube videos without encryption, or block Youtube on secure subnets.

1. Youtube needs to work

2. It's not considered sensitive by the business (and I hope to god nobody uses Google credentials)

3. He can't change PCI-relevant settings or he'll get fired (and the business could potentially lose some sort of financial accreditation, or endanger a business partnership)

4. He can circumvent the requirements by disabling SSL for Youtube, which seems to be a loophole in PCI's laughable "security" requirements.

Sucks, but it happens. I'm sure he's polishing up his resumé.

2. PCI compliance requires that some connections are encrypted

3. PCI compliance requires that encrypted connections follow a set of guidelines, including no RC4 cipher

4. Rule #3 is not limited to encrypted connections mandated in rule #2; this allows people in the organization to assume that all encrypted connections are at least minimally 'secure', rather than 'some connections are secure but some are more secure than others'.

PCI compliance doesn't care about unencrypted connections, because they mandate that sensitive data travel over encrypted connections, so unencrypted connections aren't relevant to them at all.

So basically, PCI says 'no RC4 ciphers in your enterprise' (for stupid reasons) and does not allow for exceptions (for sane reasons). Google is using RC4 only (for what I assume are practical, if stupid, reasons).

It's kind of surprising, since Google (or at least, large swaths of Google) must be PCI compliant considering that they do payment processing, etc.