
YouTube requires the RC4 cipher for videos - theandrewbailey
https://productforums.google.com/forum/#!topic/youtube/hf7SDRTmwdg
======
timothya
Interesting. It looks like the page itself is encrypted with more standard
crypto using AES [0], but the video itself is served from a connection using
RC4 [1].

As far as I can tell from this article [2], attacks on RC4 are only
theoretical at this point, but it seems reasonable that they should upgrade
the video serving domain to be consistent with the page itself (though maybe
it's done for performance reasons - either encrypting a large video stream
costs a lot of CPU time or decrypting it on the client is too slow or CPU
intensive for watching video smoothly, so perhaps they are sticking with RC4
for a good reason). Still, as my old crypto prof said, "Attacks only get
better over time. They never get worse."

[0]: [http://i.imgur.com/OcpziFa.png](http://i.imgur.com/OcpziFa.png)

[1]: [http://i.imgur.com/57T8bay.png](http://i.imgur.com/57T8bay.png)

[2]:
[https://community.qualys.com/blogs/securitylabs/2013/03/19/r...](https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-
tls-is-broken-now-what)

~~~
EthanHeilman
Attacks on RC4 are publically theoretical but people have come forward to say
that the NSA[1], and likely other intelligence agencies, can break RC4 in real
time. Given what we know about the theoretical attacks, this does not stretch
the imagination.

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

~~~
tptacek
The attacks are not "theoretical". They are in fact trivial to implement. What
you mean to say here is that the attacks are difficult to launch in practice.
That is true: while the code to attack RC4 is simple, the attack generates a
huge amount of bandwidth.

------
mrb
For the record, Google has been working on adding support for more secure
ciphers [1] and the fix is being (has been?) pushed as we speak. Users already
reported seeing support for AES-GCM (see Jas Per's scan[2]).

[1]
[https://news.ycombinator.com/item?id=7775052](https://news.ycombinator.com/item?id=7775052)

[2] [https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-
uxaxo...](https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-
uxaxovg-5goz.googlevideo.com)

~~~
harshreality
It looks like one AES-GCM and one RC4 ciphersuite, but with RC4 preferred?

"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?

------
FiloSottile
> My guess is someone at Google read an outdated, incorrect blog post about
> the BEAST attack and saw the recommendation to force RC4. They then did so
> without bothering to learn anything about what they were doing.

Oh, well, no. Really, this is not something that can happen at Google. The
security people working there are for sure not clueless and a similar decision
is not taken so lightly at that scale.

What happened is that they looked into it more than OP, benchmarked it and
decided that the performance overhead of a cipher different from RC4 was not
acceptable for the video streams. Or they have hardware streaming those videos
that only supports RC4.

It's not small play as OP seems to believe. I'm actually amazed that they
enabled AES-GCM as a fallback. Btw, RC4 remaining preferred points more in the
direction of performance reasons.

------
lnanek2
Honestly, I couldn't care less if my YouTube video stream was encrypted or
not. So I'm on the side of the original poster. That said, Google obviously is
against that. So I guess he should have just pushed for newer cipher support
saying RC4 was not legally possible for his organization. Google adding
support for newer ciphers and getting more users seems like a clear win for
them and probably only takes their equivalent of updating a Chef or other
infrastructure recipe since it is just a setting.

------
khaki54
RC4 is faster and less cpu intensive -- Leading to a better user experience,
and lower costs which is probably why they force it.

I know a lot of times we prefer arcfour (RC4) for backend "trusted" ssh
connections because it is faster the other ciphers.

~~~
billyhoffman
tldr: AES-NI is faster than RC4 on Intel processors > 2009\. 170% faster
actually [5]

"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](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](http://en.wikipedia.org/wiki/AES_instruction_set)

4- [http://zombe.es/post/4078724716/openssl-cipher-
selection](http://zombe.es/post/4078724716/openssl-cipher-selection)

5- [https://istlsfastyet.com/](https://istlsfastyet.com/)

~~~
0x006A
is AES-NI available for ssh connections? Would be interesting to see an
updated benchmark like [http://blog.famzah.net/2010/06/11/openssh-ciphers-
performanc...](http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-
benchmark/) if it is.

~~~
billyhoffman
AES-NI is an extension of the instruction set of the CPU just like x64
extensions, or the older MMX, MMX2, SSE style extensions. They are opcodes
that are hardwired into the CPU itself.

Software has to be compiled to take advantage of these additional
instructions. Much like how you can compile software for say, i586 instead of
i386, and get code that executes faster. so it all depends on how OpenSSH is
compiled (and, to some extent, whether the OpenSSH source code has extract
compiler flags/code sections)

------
atoponce
People only disable RC4 due to PCI audits, because PCI vendors think RC4 is
practically broken. It's not. In practice, it's still secure:
[https://en.wikipedia.org/wiki/RC4#Security](https://en.wikipedia.org/wiki/RC4#Security).
The only way to practically attack RC4 is to obtain a "large number of TLS
encryptions". How much?

"The number of connections/sessions needed to reliably recover these plaintext
bytes is around 2^30, but already with only 2^24 connections/sessions, certain
bytes can be recovered reliably."

This is even more than what is provided in a YouTube video.

You need 16 million connections with 1GB of data, _in_ _each_ _connection_ to
practically attack RC4. Sure, treat that as a wakeup call, but let's be
realistic about it. RC4 is only _theoretically_ broken, similarly to SHA1.

By comparison, OpenSSH still uses MD5 hashes for their private server and
client keys. MD5 is practically broken. So, if you want to "do something", fix
OpenSSH.

~~~
tptacek
That is a really poor analysis. RC4 is not "secure". RC4 is terribly broken,
it's just not broken in a way that's likely to be relevant to Youtube. You
should probably get your crypto analysis from Crypto Stack Exchange, not from
Wikipedia.

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.

~~~
atoponce
Funny. I'm getting the analysis from Daniel Bernstein and other
cryptographers, not Wikipedia. I'm only showing Wikipedia, because it cites
the references:

[http://blog.cryptographyengineering.com/2013/03/attack-of-
we...](http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-
kind-of-broken-in.html)

[http://www.isg.rhul.ac.uk/tls/](http://www.isg.rhul.ac.uk/tls/)

[http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7...](http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5)

RC4 is not practically broken. It requires too many connections (about 16
million, give or take), getting identical data with different keys, and it
requires GB of data for analysis.

EDITED TO ADD: I agree we should move off it, but as I understand the current
attacks, only small pieces of information can be retrieved from RC4 in a
practical attack. With that said, the practicality of the attack is on the
edge of feasibility, and it's only going to improve over time. So move, but
don't lose any sleep over it.

~~~
tptacek
I don't know how to respond to this. 16 million connections is nothing.
Gigabytes of data is nothing. Home Internet users incur gigabytes of bandwidth
expense to get Torrented copies of movies they don't even end up watching.

I don't know how much clearer I can say this: RC4 is breakable with attacks
that take mere hundreds of lines of code, and the attacks are bounded only by
your ability to generate millions of connections and gigabytes of transferred
bytes. It's 2014.

I'm getting some of my analysis from Bernstein and Patterson too, but more of
it from the experience of having implemented some of the attacks, and working
directly with people who have implemented the rest of them. You should take my
word for this and stop using RC4. The attack is not "on the edge of
feasibility". Yes, the attacks have been leveraged to recover "small pieces of
data" from connection. That's because the data you care about in an HTTPS
connection is small: you're trying to recover the session cookie.

~~~
kstrauser
With due respect, LOC seems like an awful metric to gauge protocol brokenness.
I can write a one-liner that counts to 2^128, but that doesn't demonstrate
that it's easy to count that high.

~~~
tptacek
Which is why I didn't just cite LOC. There are attacks that requires many
millions of ciphertexts _and_ that are difficult to implement (for instance,
they might speed up a brute-force search). That's not what the RC4 attacks
are; they're a simple statistical process that directly reveals plaintext
bytes.

------
PeterGriffin
Is this me, or does the linked thread read like a warning about the brain
damage bureaucracy can do to people?

tl;dr

\- A company wants to be PCI compliant.

\- PCI forbids using RC4 encoding.

\- YouTube now requires encryption and uses RC4 for the actual video stream (I
guess for performance reasons).

\- Company employee thinks that opening YouTube somehow damages their PCI
compliance, because the site uses RC4.

\- The company employee would rather have YouTube serve its site _with no_
encryption, rather than use RC4, as somehow this would be _better_ for their
PCI compliance.

What am I missing here that makes this less absurd?

~~~
saidajigumi
The OP in that thread made it quite clear in a subsequent post:

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

------
mahouse
googlevideo.com is a CDN. Up to what point do they control it?

~~~
theandrewbailey
Most (if not all) other Google properties have no trouble supporting better
encryption. This is probably an oversight.

~~~
drzaiusapelord
Or its for performance reasons. Grandma's computer might have issues decoding
flash video in whatever codec it now uses (h264 I assume) that's also wrapped
in 128/256-AES coming to her at HD quality.

