3 ms·

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

by Area12 9y 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?

Area12 9y ago
Oh boy did that list come out poorly, let me try again: 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
hannob 9y ago
> Why still support the TLS_RSA_* ciphers, given that they, unlike TLS 1.1, have a known vulnerability? 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.)
- Area12 9y ago
  So ... why do they continue with tls_rsa? Is it required because of middleboxes lagging behind?

by Area12 9y ago

Area12 9y ago

Oh boy did that list come out poorly, let me try again: 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

hannob 9y ago

> Why still support the TLS_RSA_* ciphers, given that they, unlike TLS 1.1, have a known vulnerability? 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.)

Area12 9y ago
So ... why do they continue with tls_rsa? Is it required because of middleboxes lagging behind?