TLS ClientHello 中 Cipher Suites 必须有 5 个吗

80 天前
 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 包,完全不考虑安全性)

1441 次点击
所在节点    程序员
14 条回复
yolee599
80 天前
这是服务端和客户端共同协商的,我见过只有两个的,应该也可以只有一个
tool2d
80 天前
似乎没这种说法,客户端给的都是 hint ,最终还是服务器来决定用哪一个算法。

可以用 https://www.ssllabs.com/测试一下,服务器评分点之一,就在于避免使用老版本的加密算法。
ZRS
80 天前
有没有可能是服务端做了 TLS fingerprint 的校验,来反 bot
salmon5
80 天前
我试了下,可以只启用 TLSv1.3 TLS_AES_256_GCM_SHA384 ,chrome,firefox,edge 浏览器都没问题。
RHEL8-9 curl 请求正常。RHEL7 curl 请求失败。
salmon5
80 天前
可以只 1 个,5 个或者 5 个以上,是为了保持兼容。
salmon5
80 天前
TLS v1.3 是恰好 5 个,目前都是合规的。
TLS v1.2 就多了,合规这个要看安全和兼容的权衡。
https://www.ssllabs.com/ssltest/ 可以分析 google.com,apple.com,tesla.com
leonshaw
80 天前
可能是跟服务端没有交集,也可能是风控策略
jim9606
80 天前
前三个是 TLS1.3 定义的套件,第四个是 TLS1.0+可用的套件,最后一个是防降级攻击定义的套件。
所以少了第四个会导致不支持 1.3 的服务器握手失败。

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

以上优化是建立在专用客户端/服务器上,没有向前兼容的情况。
0o0O0o0O0o
80 天前
@jim9606

> 或者直接上 http3

直接上 http3 更省流量的原理是什么?
jim9606
80 天前
而且我是不明白,不在意安全性你为啥要整 TLS,图啥?
jim9606
80 天前
@0o0O0o0O0o
HTTP3 大致就是 HTTP2 over QUIC ,不过将这俩深度集成在一起了,主要是直接打包了前面所提的 session ticket/0rtt 等改进,并支持连接迁移(客户端换网络不需要重新握手)。如果就是打算在里面跑 http 的可以直接上 http3 (跳过 Alt-Svc 升级)。
省流量其实不算是 HTTP3 的改进目标,出发点是减少握手的话按上面恰当配置 TLS1.3 应该也差不多,而且应该不会比用 PSK 密码套件(毕竟这玩意的安全性太差)的 TLS 省流量。
0o0O0o0O0o
80 天前
@jim9606 #11 有一个问题是基于 UDP 的 QUIC 在理想环境和真实环境中是否能省流量
yutian2211
79 天前
8L 正解啊,Client Hello 只是在协商使用 PSK 罢了
iqoo
79 天前
@jim9606 URL 是第三方提供的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1016295

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX