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