【问题标题】:Is it possible to use TLSv1.3 ciphers in TLSv1.2 session?是否可以在 TLSv1.2 会话中使用 TLSv1.3 密码?
【发布时间】:2019-02-04 06:38:35
【问题描述】:

我正在反转一个 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 及更低版本。

现在,这个应用程序做了一些非常奇怪的事情:

它在“Client Hello”期间使用 TLSv1.2 和新的 TLSv1.3 密码,而同样支持 TLSv1.3 的服务器允许它并出于某种原因开始通信。

这怎么可能?谢谢。

【问题讨论】:

    标签: ssl networking https openssl tls1.2


    【解决方案1】:

    不,我认为您缺少一个重要的新方面(我看不到您的链接图片,您应该在问题本身中发布所有相关数据)。

    出于兼容性原因,TLSv1.3 在ClientHello 期间尝试将自身掩蔽为 TLSv1.2,请参阅https://www.rfc-editor.org/rfc/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 被识别为具有 0x0303 的 legacy_version 和 supported_versions 扩展 以 0x0304 作为其中指示的最高版本。 (有关向后兼容性的详细信息,请参阅附录 D。)

    至于密码套件和 TLS 版本,情况更加复杂。出于规范中解释的原因,TLSv1.3 仅将其中一些标准化为强制性的。 但是,这也没有严格禁止其他 TLS 版本使用它们。

    见:

    “AES GCM”系列于 10 年前在 https://www.rfc-editor.org/rfc/rfc5116 中定义 TLSv1.3 仅对完美前向隐私进行标准化,因此这意味着仅 (EC)DHE 密钥交换,如果不使用 PSK(请参阅 RFC8446 的第 2 节)

    看看https://security.stackexchange.com/a/77018/137710https://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://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL- 上的 CloudFlare 文档如下表所示:

    虽然 TLS 1.3 使用与以前版本的 TLS 相同的密码套件空间,但 TLS 1.3 密码套件的定义不同,仅指定对称密码,不能用于 TLS 1.2。同样,TLS 1.2 和更低的密码套件不能与 TLS 1.3(IETF TLS 1.3 草案 21)一起使用。

    【讨论】:

    • 非常感谢您的回复,非常详尽。问题是,由于我使用的是 mitmproxy,我的手机正在启动与代理服务器的 TLSv1.2 会话,但代理服务器正在与 AppServer 启动 TLSv1.3 会话,这会导致错误,因为据我所知,代理服务器无法将数据发送回客户端(电话),从而导致警报(级别:致命,描述:协议版本)。有什么想法吗?
    • 根据我现在看到的图像,如果没有别的,这真的是 NOT TLSv1.3,因为它的规范要求 ClientHello 具有我所做的扩展“supported_versions”没看到。
    • 那么,他们如何在 TLSv1.2 中使用新密码?有没有办法编译 openSSL 来做到这一点?
    • 如果您的代理终止了两个 TLS 流,它当然可以是您的客户端的 TLSv1.2 服务器,同时也可以是某个使用 TLSv1.3 的服务器的 TLSv1.3 客户端
    • 这是通信客户端->proxyserver i.imgur.com/SZ73skI.png 这是通信代理服务器->appserver i.imgur.com/Crka0X6.png
    猜你喜欢
    • 2022-08-18
    • 2021-07-27
    • 2016-05-16
    • 1970-01-01
    • 2012-11-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多