While this is an excellent summary of the RC4 attack and a good prioritized list of ciphers to use, it's still important to note that the vast majority of TLS-related vulnerabilities involve improper use of TLS libraries, plain old misconfiguration, and questionable certificate authorities. See "The Most Dangerous Code in the World" (https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf) for a sobering account.
Having personally implemented certificate validation logic (for tlslite, though it's not mainlined yet), my own sense is that the X.509 validation process has now become so complicated that it violates any reasonable person's definition of a minimal "trusted computing base" (cf. microkernels for more philosophical discussion of minimality as a security goal). For example, see section 7 of RFC 5280: name validation alone now subsumes all the complexity of Unicode normalization.
- Chrome Stable support TLS 1.1, Chrome Beta/Canary support TLS 1.2
- Firefox Stable support TLS 1.0. You can enable TLS 1.1 by setting "security.tls.version.max" to "2" in about:config. Support is not considered stable, and you might have some problems: https://bugzilla.mozilla.org/show_bug.cgi?id=733647
- Firefox Aurora/Nightly supports TLS 1.0. You can enable TLS 1.1/1.2 by setting "security.tls.version.max" to "3" in about:config. Like Firefox Stable, support is not considered stable and you might have some problems.
- Opera 15 support TLS 1.1.
- Opera 12 support TLS 1.0. You can enable TLS 1.1/1.2 by checking "Enable TLS v1.1" and "Enable TLS v1.2" in opera:config
> That's what the latest RC4 attack shows. Specifically, there are biases in the first 256 bytes of keystream generated by RC4. Those first bytes are likely to be used to encrypt the start of an HTTP request and may include sensitive information such as a cookie used for logging into a web site.
I didn't pick this up from the previous discussions on the vulnerability. Basically, RC4 is vulnerable under an HTTP request/response usage pattern--one where you make lots of little TLS connections that share some initial plaintext worth protecting.
In other words, if you've written a webapp which does everything over one long-lived TLS websocket (including doing the client authentication after the connection upgrade using websocket messages, rather than transmitting that in a cookie), then you have much less to worry about, and RC4 can probably be safely preferred to AES-CBC ciphers in your ciphersuite configuration. Though you still might consider padding your websocket connection with an initial 256 bytes of meaningless data that the server knows to ignore (which is not much additional overhead relative to the lifetime of the socket, really.)
I don't think this is true. I think you're assuming that the vulnerability has anything to do with how your app works, when it in fact targets browser behavior. The attacker uses (e.g.) Javascript, loaded from some random site, to generate a bajillion connections to your site, each of which will bear session cookies.
The 256 byte padding doesn't help either, because of the Fluhrer-McGrew biases.
I'm curious why CloudFlare includes !EDH as part of their cipher suite options... Guessing they were just following the recommendations from https://community.qualys.com/blogs/securitylabs/2011/10/17/m..., but having a specific reason would be interesting to know. EDH ciphers are generally slower (so I could see why a company that wants connections to be fast wouldn't want to use them), but at the same time, they also allow for forward secrecy. Seems like CloudFlare might want to prioritize forward secrecy over speed, as per http://blog.cloudflare.com/cloudflare-prism-secure-ciphers. Maybe I'm missing something here, though... Perhaps that !EDH should be !ADH?
From Adam Langley, who works at Google on their SSL stack, on his post "How to botch TLS forward secrecy":
In the case of multiplicative Diffie-Hellman (i.e. DHE), servers are free to choose their own, arbitrary DH groups. <snip> ... it's still the case that some servers use 512-bit DH groups, meaning that the connection can be broken open with relatively little effort.
Nice write-up of the current state. I've been more and more interested in the process of moving to ECC. Some CAs are issuing dual certs (ECC and RSA), but I'm not sure how good support in browsers and client libs is.
One key takeaway from a security course I followed at uni was to never use a stream cipher if avoidable. They tend to be much more malleable than block ciphers, and are generally less understood.
Does anyone know why CloudFlare uses TLS internally? I'm assuming they mean over their intranet of web servers, so if those are behind a firewall with their iptables configured properly, then what's the point of using TLS?
We have 23 locations around the world where we have servers. Those servers need to be administered, monitored, backed up, rebooted, and synchronized. So we make extensive use of SSH and TLS.
Yes, there are all sorts of firewalls and iptables rules to create an 'intranet' across the world, but that doesn't stop the actual packets from passing the public Internet. There's really no reason not to use TLS.
It's long been a best practice for highly secure environments to use transport encryption between all tiers. The idea is that if someone compromises your datacenter, it's often a second-tier box, a forgotten web app, an ssh bastion host, etc. These boxes might not have any sensitive information on them.
However, the attacker might be able to use that box as a jumping off point to attack switches or other network devices where you could configure the network port of a compromised machine to receive a copy of all of the data being transmitted on the ports of more sensitive servers.
You should treat external firewalls and iptables like seatbelts in cars - yes, they're great, yes, you're a lot more likely to survive something terrible with them, but that doesn't mean you can drive recklessly and drunk.
[+] [-] dmbaggett|12 years ago|reply
Having personally implemented certificate validation logic (for tlslite, though it's not mainlined yet), my own sense is that the X.509 validation process has now become so complicated that it violates any reasonable person's definition of a minimal "trusted computing base" (cf. microkernels for more philosophical discussion of minimality as a security goal). For example, see section 7 of RFC 5280: name validation alone now subsumes all the complexity of Unicode normalization.
[+] [-] Spittie|12 years ago|reply
https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_b...
Basically:
- Chrome Stable support TLS 1.1, Chrome Beta/Canary support TLS 1.2
- Firefox Stable support TLS 1.0. You can enable TLS 1.1 by setting "security.tls.version.max" to "2" in about:config. Support is not considered stable, and you might have some problems: https://bugzilla.mozilla.org/show_bug.cgi?id=733647
- Firefox Aurora/Nightly supports TLS 1.0. You can enable TLS 1.1/1.2 by setting "security.tls.version.max" to "3" in about:config. Like Firefox Stable, support is not considered stable and you might have some problems.
- Opera 15 support TLS 1.1.
- Opera 12 support TLS 1.0. You can enable TLS 1.1/1.2 by checking "Enable TLS v1.1" and "Enable TLS v1.2" in opera:config
- IE 10 support TLS 1.0. You can enable TLS 1.1/1.2 by enabling them in Windows, and forcing IE to use them. See http://netsekure.org/2009/10/tls-1-2-in-windiows-7/
You can use sites like https://sni.velox.ch/ and https://cc.dcsec.uni-hannover.de/ to see which version of TLS is your browser using.
[+] [-] derefr|12 years ago|reply
I didn't pick this up from the previous discussions on the vulnerability. Basically, RC4 is vulnerable under an HTTP request/response usage pattern--one where you make lots of little TLS connections that share some initial plaintext worth protecting.
In other words, if you've written a webapp which does everything over one long-lived TLS websocket (including doing the client authentication after the connection upgrade using websocket messages, rather than transmitting that in a cookie), then you have much less to worry about, and RC4 can probably be safely preferred to AES-CBC ciphers in your ciphersuite configuration. Though you still might consider padding your websocket connection with an initial 256 bytes of meaningless data that the server knows to ignore (which is not much additional overhead relative to the lifetime of the socket, really.)
[+] [-] tptacek|12 years ago|reply
The 256 byte padding doesn't help either, because of the Fluhrer-McGrew biases.
[+] [-] JoachimSchipper|12 years ago|reply
[+] [-] reedloden|12 years ago|reply
[+] [-] jamesvl|12 years ago|reply
In the case of multiplicative Diffie-Hellman (i.e. DHE), servers are free to choose their own, arbitrary DH groups. <snip> ... it's still the case that some servers use 512-bit DH groups, meaning that the connection can be broken open with relatively little effort.
Full article of his at https://www.imperialviolet.org/
[+] [-] jarito|12 years ago|reply
[+] [-] norswap|12 years ago|reply
[+] [-] tptacek|12 years ago|reply
[+] [-] mikegioia|12 years ago|reply
[+] [-] jgrahamc|12 years ago|reply
Yes, there are all sorts of firewalls and iptables rules to create an 'intranet' across the world, but that doesn't stop the actual packets from passing the public Internet. There's really no reason not to use TLS.
[+] [-] mattzito|12 years ago|reply
However, the attacker might be able to use that box as a jumping off point to attack switches or other network devices where you could configure the network port of a compromised machine to receive a copy of all of the data being transmitted on the ports of more sensitive servers.
You should treat external firewalls and iptables like seatbelts in cars - yes, they're great, yes, you're a lot more likely to survive something terrible with them, but that doesn't mean you can drive recklessly and drunk.
[+] [-] 46Bit|12 years ago|reply
[+] [-] JulianMorrison|12 years ago|reply
[+] [-] tptacek|12 years ago|reply