davidben

4 ms·

1.
by davidben 10y ago
Ultimately we can't do anything about a server that is near-maliciously determined to be wrong. The hope is we can at least defend against some of the common genuine mistakes at fairly low cost. The implementer that tries to special-ca
2.
by davidben 10y ago
The blog isn't quite right. HTTP/2 requires ECDHE (or DHE, but don't do that) with an AEAD, which means one of the GCMs or CHACHA20_POLY1305 if you have it. It's written as a blacklist, but this was the intent. What&#x27
3.
by davidben 11y ago
SSLLabs capping server scores for just supporting RC4 is kind of silly. The server gets to pick the cipher and the Finished message authenticates the rest of the handshake. So long as the key exchange portion is strong enough (and that&#x27
4.
by davidben 12y ago
AES_128_GCM is much much preferable to AES_256_CBC. AES_256_GCM does not have broad support (not supported by Chrome or Firefox) and isn't really worth the performance tradeoff. https://code.google.com/p/chromium&#
5.
by davidben 12y ago
This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and d
6.
by davidben 13y ago
It's been fixed, but that was a bug in Chrome's NSS glue between NSS and the OS X native key store. (The fix is under third_party/nss, but no one else carries that particular file.) As far as I know, it works fine on other pl