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
- 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.
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.)
The 256 byte padding doesn't help either, because of the Fluhrer-McGrew biases.
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/
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.
Here's what we are currently using:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
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.