是否可以在TLSv1.2会话中使用TLSv1.3密码? [英] Is it possible to use TLSv1.3 ciphers in TLSv1.2 session?
问题描述
我正在反转一个Android应用程序，并且在嗅探时发现有些奇怪的事情发生.
TLSv1.3引入了一些新密码，例如
- 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
而且，根据我在OpenSSL文档中所读的内容( https://wiki .openssl.org/index.php/TLS1.3 )，
有一些新的密码套件只能在TLSv1.3中使用.旧的密码套件不能用于TLSv1.3连接，而新的密码套件不能用于TLSv1.2及以下版本.
现在，此应用程序执行了一些非常奇怪的操作:.
它在客户端问候"期间使用带有新TLSv1.3密码的TLSv1.2，并且服务器也支持TLSv1.3，允许它，并且由于某种原因，它们开始通信.
那怎么可能?谢谢.
不，我想念一个重要的新方面(我看不到链接的图像，应该将所有相关数据发布到问题本身内.) /p>
出于兼容性原因，TLSv1.3尝试在ClientHello期间将其自身屏蔽为TLSv1.2，请参见 https://tools.ietf.org/html/rfc8446#section-4.1.2 :
4.1.2.客户您好
当客户端首次连接到服务器时，需要发送 ClientHello作为其第一条TLS消息.
此消息的结构:
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;
请注意，legacy_version实际上是TLSv1.2，然后进行了说明:
legacy_version:在以前的TLS版本中，此字段用于 版本协商，并代表最高版本号 客户支持.经验表明，许多服务器 没有正确实施版本协商，导致版本 不容忍"，其中服务器拒绝接受其他方式可以接受的 版本高于其支持版本的ClientHello.在 TLS 1.3，客户端在 "supported_versions"扩展名(第4.2.1节)和 legacy_version字段必须设置为0x0303，即版本 TLS 1.2的编号. TLS 1.3 ClientHellos被确定为具有 legacy_version为0x0303，supported_versions扩展名 当前的最高版本为0x0304. (有关向后兼容性的详细信息，请参阅附录D.)
对于密码套件和TLS版本，情况更为复杂.出于规范中说明的原因，TLSv1.3仅将其中的一部分标准化为强制性的. 但是，这也不严格禁止其他TLS版本也使用它们.
请参阅:
- 用于传输层安全性(TLS)的ChaCha20-Poly1305密码套件:此该文档描述了ChaCha流密码的使用和 传输层1.2版或更高版本中的Poly1305身份验证器 安全(TLS)协议
- 用于长期支持的TLS 1.2更新使用AES + SHA
"AES GCM"家族是10年前在 https://tools.ietf.org中定义的/html/rfc5116 TLSv1.3仅在完美的前向隐私上进行了标准化，因此，如果不使用PSK，则仅意味着(EC)DHE密钥交换(请参阅RFC8446的第2部分)
看看 https://security.stackexchange.com/a/77018/137710 和 https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
但是TLSv1.3密码套件的定义有所不同，使用了新名称，因为以前的名称不再适用，因为TLS 1.3在使用算法方面做出了一些选择，等等，从而消除了某些部分的波动性.
因此，您将在OpenSSL更新日志中看到此警告:
从TLSv1.2密码套件中分离出TLSv1.3密码套件配置 配置. TLSv1.3密码套件与TLSv1.2和 以下.同样，TLSv1.2密码套件与TLSv1.3不兼容. 为了避免遗留TLSv1.2密码套件配置的问题 否则会无意中禁用所有TLSv1.3密码套件 配置已被分离出来.请参见密码手册页或 有关更多信息，请参见SSL_CTX_set_ciphersuites()手册页.
( https://github.com/openssl/openssl/pull/5392)
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.
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).
这篇关于是否可以在TLSv1.2会话中使用TLSv1.3密码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
