问题
I'm reversing an Android application and I noticed, while sniffing, that something weird happens.
TLSv1.3 introduces few new ciphers such as
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
And, from what I've read on OpenSSL documentation (https://wiki.openssl.org/index.php/TLS1.3),
There are new ciphersuites that only work in TLSv1.3. The old ciphersuites cannot be used for TLSv1.3 connections and the new ones cannot be used in TLSv1.2 and below.
Now, this application does something very strange: .
It is using TLSv1.2 with new TLSv1.3 ciphers during "Client Hello" and server, which also supports TLSv1.3, allows it and they start the communication for some reason.
How is that possible? Thank you.
回答1:
No, you are missing an important new aspect I think ( I can not see your linked image, you should post all relevant data inside the question itself).
For compatibility reasons, TLSv1.3 try to mask itself as TLSv1.2 during ClientHello, see https://tools.ietf.org/html/rfc8446#section-4.1.2 :
4.1.2. Client Hello
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first TLS message.
Structure of this message:
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
Note the legacy_version being TLSv1.2 in fact, and then the explanation:
legacy_version: In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein. (See Appendix D for details about backward compatibility.)
As for cipher suites and TLS versions, the situation is more complicated. TLSv1.3 standardized only a few of them as mandatory, for reasons explained in the specification. However that does not strictly forbid other TLS versions to use them either.
See:
- ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS): This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in version 1.2 or later of the Transport Layer Security (TLS) protocol
- TLS 1.2 Update for Long-term Support with AES+SHA
The "AES GCM" family was defined 10 years ago in https://tools.ietf.org/html/rfc5116 TLSv1.3 standardized on only perfect forward privacy so that meant only (EC)DHE key exchanges, if not using PSK (see section 2 of RFC8446)
Have a look at https://security.stackexchange.com/a/77018/137710 and https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
But the TLSv1.3 ciphers suite is defined differently, using new names, because previous ones were not relevant anymore, as TLS 1.3 made some choices about algorithms to use, etc. that removes volatility in some parts.
Hence you will see this warning in OpenSSL changelog:
Separated TLSv1.3 ciphersuite configuration out from TLSv1.2 ciphersuite configuration. TLSv1.3 ciphersuites are not compatible with TLSv1.2 and below. Similarly TLSv1.2 ciphersuites are not compatible with TLSv1.3. In order to avoid issues where legacy TLSv1.2 ciphersuite configuration would otherwise inadvertently disable all TLSv1.3 ciphersuites the configuration has been separated out. See the ciphers man page or the SSL_CTX_set_ciphersuites() man page for more information.
(https://github.com/openssl/openssl/pull/5392)
CloudFlare documentation on https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL- says below table:
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3 (IETF TLS 1.3 draft 21).
来源：https://stackoverflow.com/questions/52078021/is-it-possible-to-use-tlsv1-3-ciphers-in-tlsv1-2-session