TLS ClientHello 中 Cipher Suites 必须有 5 个吗

[iqoo]

试了下至少需要这 5 个：

Cipher Suites (5 suites)
    Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
    Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

有些网站少一个就握手失败，有些可以少几个。

查了下文档 https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4 ，里面写着：

   This specification defines the following cipher suites for use with
   TLS 1.3.

              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

文档是 TLS 1.3 版本的，对于之前的版本，也必须提供至少 5 个吗？

（场景：节省客户端发送流量，用最小的 ClientHello 包，完全不考虑安全性）

[yolee599]

这是服务端和客户端共同协商的，我见过只有两个的，应该也可以只有一个

[tool2d]

似乎没这种说法，客户端给的都是 hint ，最终还是服务器来决定用哪一个算法。

可以用 https://www.ssllabs.com/测试一下，服务器评分点之一，就在于避免使用老版本的加密算法。

[ZRS]

有没有可能是服务端做了 TLS fingerprint 的校验，来反 bot

[salmon5]

我试了下，可以只启用 TLSv1.3 TLS_AES_256_GCM_SHA384 ，chrome,firefox,edge 浏览器都没问题。
RHEL8-9 curl 请求正常。RHEL7 curl 请求失败。

[salmon5]

可以只 1 个，5 个或者 5 个以上，是为了保持兼容。

[salmon5]

TLS v1.3 是恰好 5 个，目前都是合规的。
TLS v1.2 就多了，合规这个要看安全和兼容的权衡。
https://www.ssllabs.com/ssltest/ 可以分析 google.com,apple.com,tesla.com 的

[leonshaw]

可能是跟服务端没有交集，也可能是风控策略

[jim9606]

前三个是 TLS1.3 定义的套件，第四个是 TLS1.0+可用的套件，最后一个是防降级攻击定义的套件。
所以少了第四个会导致不支持 1.3 的服务器握手失败。

还有如果是想省流量，缩减 clienthello 属于思路错了，你应该考虑的是跳过握手和缩减服务器证书链，包括 TLS1.3 PSK(也就是 session ticket 扩展)、0rtt early data(有重放风险，只能用在幂等请求)，或者直接上 http3(要考虑 udp 联通性问题)。低安全要求又没可靠时钟的可以考虑用 PSK 套件。

以上优化是建立在专用客户端/服务器上，没有向前兼容的情况。

[0o0O0o0O0o]

@jim9606

> 或者直接上 http3

直接上 http3 更省流量的原理是什么？

[jim9606]

而且我是不明白，不在意安全性你为啥要整 TLS,图啥？

[jim9606]

@0o0O0o0O0o
HTTP3 大致就是 HTTP2 over QUIC ，不过将这俩深度集成在一起了，主要是直接打包了前面所提的 session ticket/0rtt 等改进，并支持连接迁移（客户端换网络不需要重新握手）。如果就是打算在里面跑 http 的可以直接上 http3 （跳过 Alt-Svc 升级）。
省流量其实不算是 HTTP3 的改进目标，出发点是减少握手的话按上面恰当配置 TLS1.3 应该也差不多，而且应该不会比用 PSK 密码套件(毕竟这玩意的安全性太差)的 TLS 省流量。

[0o0O0o0O0o]

@jim9606 #11 有一个问题是基于 UDP 的 QUIC 在理想环境和真实环境中是否能省流量

[yutian2211]

8L 正解啊，Client Hello 只是在协商使用 PSK 罢了

[iqoo]

@jim9606 URL 是第三方提供的