|
|
|
|
|
|
by Area12
3064 days ago
|
|
|
I notice that ssllabs.com/ssltest lists the cipher suites uses at github engineering as: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK Why still support the TLS_RSA_* ciphers, given that they, unlike TLS 1.1, have a known vulnerability?
Is it mainly because of middleboxes that can't handle ciphers that all modern up-to-date browsers can? |
|
|
TLS 1.1 also has known by design vulnerabilities. It only supports two cipher modes, RC4 and CBC/HMAC. The first is vulnerable to biases, the second to padding oracles + Lucky 13.
Yeah, padding oracles can be avoided by implementing crazy, complicated countermeasures. Same is true for TLS_RSA. (Though I do agree that TLS_RSA is probably more problematic.)