If you can modify the browser, modify it to use a ciphersuite that doesn't have these problems!
As a shorthand: workarounds are only fair game if they don't require software updates by Microsoft or Mozilla. So, for instance, having Rails treat session tokens as one-time-use does mitigate this flaw (somewhat) and is fair game. But having Firefox randomize client headers is not useful, compared to getting Firefox to reliably do AES-GCM (which I think Firefox may be close to doing already).
I've seen you recommend GCM in a couple of places in this topic. I'm not a crypto guy, so I rely on people like you for this stuff.
Other experts I've read (Colin Percival, Thomas Pornin) have mentioned that GCM (and other encrypt-and-mac) implementations are more likely to to have chosen-ciphertext vulnerabilities with respect to CTR mode then MAC.
Can you cite either Colin or Pornin on that? It's easy to find Pornin saying positive things about the AES-GCM TLS ciphersuite.
I don't know what you mean by "chosen-ciphertext vulnerabilities". Authenticated encryption is inherently less vulnerable to chosen-ciphertext, because the ciphertext is integrity-checked. You can't choose an arbitrary new ciphertext, because it won't pass the MAC. In fact, it's the opposite construction --- MAC-then-encrypt --- that causes chosen-ciphertext flaws; a MAC-then-encrypt construct is what got us Lucky 13.
I was wrong on Pornin. I was remembering a crypto.stackexchange question in which Pornin participated, but he did not say anything specifically about GCM or encrypt-and-mac modes. It does look like he's referencing another answer that is no longer there. The quote I remembered was from Vennard (below) and this answer was marked as accepted by Pornin.
Vennard:
under encrypt-and-mac method:
> No integrity on the ciphertext again, since the MAC is taken against the plaintext. This opens the door to some chosen-ciphertext attacks on the cipher, as shown in section 4 of Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm.
This may not apply specifically to GCM; I'm not sure if the MAC validates plaintext or ciphertext.
GCM authenticates the ciphertext, not the plaintext.
Colin doesn't marshal a specific argument against GCM here, but rather a philosophical one. And his argument is wrong: if you look at the histories of SSL/TLS, SSH, and Tor, you find that the stuff that goes wrong is in code that tries to do simple stuff like combine a block cipher with a hash MAC (which is exactly what he's arguing for here).
GCM, on the other hand, is a NIST standard; you don't have the degrees of freedom with how you e.g. handle padding, or nonce generation, or when you apply a MAC that you do with bespoke crypto.
Obviously, I agree with Colin that generalist developers shouldn't be writing their own AES-GCM libraries. Where Colin and I differ is that I think generalist developers shouldn't be writing crypto code at all. Leave that stuff to the Adam Langley's of the world.
I think Thomas Pornin's [reply](http://security.stackexchange.com/questions/20464/when-authe...) (and our subsequent back-and-forth) to a question of mine on the security StackExchange highlights exactly how hard it is to Encrypt-Then-MAC yourself properly.
You should use a separate key for the encrypt phase and MAC phase. You must MAC the ciphertext, the IV, the authenticated data, and possibly a specifier for the encryption algorithm. You must also construct the MAC'd string in a way that prevents tampering with field boundaries.
And if it breaks connections to servers set up to use RC4 specifically?
Sure, the browser should stop "suggesting" they use RC4. That is the browser's right. But if the server decides to use it anyway then they use it.
Also you kind of break your own rule. If we cannot suggest things which Microsoft or Mozilla have to do then we cannot suggest they alter their ciphersuite either...
Then it seems like the right solution is to push TLS 1.2 + AES-GCM along with fixes for Lucky 13, and use CBC for everything before 1.2 and GCM for everything after it.
