4 ms·

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

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.

AlyssaRowan 12y ago
Um, no. People disable RC4 because it's rubbish. 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-02 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 https://tools.ietf.org/html/rfc6594
Someone1234 12y ago
> 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. 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.
- atoponce 12y ago
  No. I meant OpenSSH. See a previous reply.
tedunangst 12y ago
By comparison, OpenSSH still uses MD5 hashes for their private server and client keys. Can you clarify?
- atoponce 12y ago
  When you initiate a connection to an OpenSSH server, the server presents you with its public key, which is hashed with MD5, and the result displayed. You _should_ verify this with the server administrator that the fingerprints matched, and you are indeed connected to the server you intended, rather than a hijacked connection. MD5 is resistant to 2nd preimage attacks, however. So technically, OpenSSH is fine using MD5 to display the fingerprint to you. With that said, I also don't see the problem moving to a stronger algorithm.
tptacek 12y ago
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 12y ago
  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-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... 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_5 http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7... 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.
  - 12y ago
sdevlin 12y ago
> You need 16 million connections with 1GB of data, _in_ _each_ _connection_ to practically attack RC4. 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.
- tptacek 12y ago

AlyssaRowan 12y ago

Um, no. People disable RC4 because it's rubbish. 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-02 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 https://tools.ietf.org/html/rfc6594

Someone1234 12y ago

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

atoponce 12y ago
No. I meant OpenSSH. See a previous reply.

tedunangst 12y ago

By comparison, OpenSSH still uses MD5 hashes for their private server and client keys. Can you clarify?

atoponce 12y ago
When you initiate a connection to an OpenSSH server, the server presents you with its public key, which is hashed with MD5, and the result displayed. You _should_ verify this with the server administrator that the fingerprints matched, and you are indeed connected to the server you intended, rather than a hijacked connection. MD5 is resistant to 2nd preimage attacks, however. So technically, OpenSSH is fine using MD5 to display the fingerprint to you. With that said, I also don't see the problem moving to a stronger algorithm.

tptacek 12y ago

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 12y ago
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-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... 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_5 http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7... 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.
- 12y ago

sdevlin 12y ago

> You need 16 million connections with 1GB of data, _in_ _each_ _connection_ to practically attack RC4. 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.

tptacek 12y ago