I performed vulnerability testing of some Android mobile applications I helped develop and I noticed some odd behavior. The applications used the default Android 5.0.2 cipher suite list that includes the
TLS_FALLBACK_SCSV (0x5600) suite designed to prevent Poodle. See cipher suite list below:
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: Unknown (0x5600)
When I looked at the TLS request sequence in the network capture it occurs over SSL 3.0 even though SSL3 isn't supported in the cipher suite list.
This doesn't look like Poodle. What i found the most interesting is that the negotiated cipher suite (in the Server Hello request) was
Does this mean the encrypted session effectively took place using the
SSL3_RSA_WITH_AES_128_CBC_SHA cipher suite? And is it vulnerable to the same SSL 3.0 CBC vulnerability used to recover plain-text data by Poodle?