Please read my blog's comment policy here.
In case you missed it, the recent Windows 8.1 Update update adds four new ciphersuites (including two supported by Chrome32) and changes the ciphersuite order to prefer algorithms that offer Perfect-Forward-Secrecy. You can read more about this update here.
Wikipedia has a nice article on PFS, but the short summary is as follows:
When your browser makes a HTTPS connection, typically, two keys are used: the client generates a random secret key that is used by a fast, symmetric (“bulk”) encryption algorithm, and it encrypts that secret using the public asymmetric key (slow) provided by the server. The problem is that if the server’s private key is ever compromised, an attacker who had previously recorded your traffic could then decrypt the secret symmetric key and turn the “gibberish” he had recorded back into the plaintext of your web session’s traffic, even if it took place months or years ago.
In PFS, each connection to the server generates a new asymmetric key pair specific to that session, such that if the server’s private key is compromised, only future traffic is at risk of disclosure.
The Windows 8.1 Update isn’t the first time that IE has supported PFS, but the new ciphersuites added in this update have performance characteristics that make servers more likely to use them.
Yea, finally usable GCM cipher suites, though they did not add GCM with ECDHE.
Good stuff, I noticed by accident already. However I have some conflicting feelings about the TLS_DHE_RSA addition. On the one hand having forward secrecy as it protects you if a website loses its key by accident.
However currently most websites that use TLS_DHE_RSA use DH parameters/key of only 1024 bits. Apache servers e.g. hardcode it at compile time. Since these DH parameters/key is roughly equal in strength as a RSA key, this means we are talking about ballpark a 1024 RSA protection only. Using 1024 RSA keys is considered very bad practice already for some time now. So in essence breaking a 1024 RSA key will break your session.
Now with TLS_DHE_RSA sessions would have to be broken 1-by-1 thanks to the Forward Security, so it is likely not that bad, but still I cannot help feeling a bit conflicted. If that session contains your password or so that won't matter ...
Also I would not call it *Perfect* Forward Security due to the low bit-strength. For instance TLS_DHE_DSS is listed by various certification sites as regular Forward Security and not 'Perfect' exactly because of the reason its key size being 1024 as well.
Anyway that is not so much Microsoft's issue but a server-issue and I know you've been bombarded and - unfairly IMHO - even criticized for not providing it sooner. My fear is that compatibility with older clients (Java6) will prevent these websites from offering higher bit strength, so we may be stuck with this issue for longer than preferred.
I would have preferred these websites just move on and provide the more modern FPS variants, instead of hammering on TLS_DHE_RSA. Now you are providing it as well, there may be even less motivation for them to do so.
[EricLaw] I've always considered the "perfect" aspect of PFS a bit of a joke.
You are right about key sizes, but I have to point out that the other "more modern FPS variants" are all based on elliptic curve discrete logarithm. Any theoretical advance on this problem would make them vulnerable. (Key sizes are small and ciphers fast because we don't known any good attack on this.) On the other hand, plain old DH and finite field discrete logarithm have been around for much longer and use key sizes designed to withstand much more sophisticated attacks (that do not extend to elliptic curves... yet). It's much better to support both, in order to be able to switch very quickly if one become severely broken.
Hmm. Why do you think the TLS_RSA_WITH_AES suites are above the TLS_ECDHE_ECDSA_WITH_AES suites? Worries about the performance of the ECDSA suites outweighing the PFS benefits?