[thirsteh]

You are extracting something I didn't say, or at least didn't mean to imply. RC4 is better than TLS-CBC as it is implemented by virtually all libraries. A constant-time implementation is obviously preferable, but considering the mess this makes of client libs I doubt many will adopt it. RC4 will be better for those until TLS 1.2 and e.g. AES-GCM are supported.

As an example, see Adam Langley's comments on not fixing (i.e. making constant-time) CBC in Go: https://groups.google.com/d/msg/golang-nuts/HF5O5vAKRcQ/3cYW...

Also, blaming browsers when we've known about timing attacks against this verification for years, and OpenSSL is patching it now, is probably a bit of a stretch.

[tptacek]

You're commenting at a greater level of detail than I am. I'm only making the AES-CBC > RC4 case because it would be awfully dumb of someone to design a new cryptosystem with RC4, even if AES-CBC was the only alternative.

The CBC timing channel 'agl is talking about is specific to TLS's idiosyncratic mac-then-encrypt implementation. Don't ever use mac-then-encrypt. Encrypt first, then MAC.

I'm blaming browsers for (a) not implementing CTR mode (AE or otherwise) and (b) being vulnerable to the chained CBC IV vulnerability. I'm not blaming browsers for the timing attack on AES-CBC.

[thirsteh]

Ah, yes. I agree.