这是一个创建于 264 天前的主题，其中的信息可能已经有所发展或是发生改变。
试了下至少需要这 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 包，完全不考虑安全性）
 |
1
yolee599 264 天前
这是服务端和客户端共同协商的，我见过只有两个的，应该也可以只有一个
|
 |
2
tool2d 264 天前
|
 |
3
ZRS 264 天前
有没有可能是服务端做了 TLS fingerprint 的校验，来反 bot
|
 |
4
salmon5 264 天前
我试了下，可以只启用 TLSv1.3 TLS_AES_256_GCM_SHA384 ，chrome,firefox,edge 浏览器都没问题。
RHEL8-9 curl 请求正常。RHEL7 curl 请求失败。 |
|
5
salmon5 264 天前
可以只 1 个，5 个或者 5 个以上，是为了保持兼容。
|
|
6
salmon5 264 天前  1
TLS v1.3 是恰好 5 个，目前都是合规的。
TLS v1.2 就多了，合规这个要看安全和兼容的权衡。 https://www.ssllabs.com/ssltest/ 可以分析 google.com,apple.com,tesla.com 的 |
 |
7
leonshaw 264 天前
可能是跟服务端没有交集，也可能是风控策略
|
 |
8
jim9606 264 天前 via Android
前三个是 TLS1.3 定义的套件，第四个是 TLS1.0+可用的套件，最后一个是防降级攻击定义的套件。
所以少了第四个会导致不支持 1.3 的服务器握手失败。 还有如果是想省流量，缩减 clienthello 属于思路错了，你应该考虑的是跳过握手和缩减服务器证书链，包括 TLS1.3 PSK(也就是 session ticket 扩展)、0rtt early data(有重放风险，只能用在幂等请求)，或者直接上 http3(要考虑 udp 联通性问题)。低安全要求又没可靠时钟的可以考虑用 PSK 套件。 以上优化是建立在专用客户端/服务器上，没有向前兼容的情况。 |
 |
9
0o0O0o0O0o 264 天前
|
|
10
jim9606 264 天前 via Android
而且我是不明白，不在意安全性你为啥要整 TLS,图啥？
|
|
11
jim9606 264 天前
@0o0O0o0O0o
HTTP3 大致就是 HTTP2 over QUIC ，不过将这俩深度集成在一起了，主要是直接打包了前面所提的 session ticket/0rtt 等改进，并支持连接迁移（客户端换网络不需要重新握手）。如果就是打算在里面跑 http 的可以直接上 http3 （跳过 Alt-Svc 升级）。 省流量其实不算是 HTTP3 的改进目标，出发点是减少握手的话按上面恰当配置 TLS1.3 应该也差不多，而且应该不会比用 PSK 密码套件(毕竟这玩意的安全性太差)的 TLS 省流量。 |
|
12
0o0O0o0O0o 264 天前 via iPhone
@jim9606 #11 有一个问题是基于 UDP 的 QUIC 在理想环境和真实环境中是否能省流量
|
 |
13
yutian2211 263 天前
8L 正解啊，Client Hello 只是在协商使用 PSK 罢了
|
Select Language