<-- 返回首页

TLS 协议 3:扩展字段

扩展字段在 ClientHello 或者 ServerHello 消息的末尾。这个网站有一份更加详细的 TLS 扩展字段,本文只选取常用的几个介绍。

Application Layer Protocol Negotiation

应用层协议协商,关于这个协议先说一段历史。之前 Google 一直在推广它的 SPDY 协议,并企图将它变成 HTTP 的新标准,事实上 HTTP/2 的制定过程中也大量参考了 SPDY。虽然 HTTP/2 是一个应用层的协议,但是几乎所有的浏览器都是在 TLS 协议之上支持 HTTP/2,也就是说 HTTP/2 都是 https 链接。Google 在开发 SPDY 时,也提出了一个新的 TLS 协议扩展 NPN,后来逐渐演化成了 ALPN。

支持 ALPN 的客户端可以使用 application_layer_protocol_negotiation 扩展提交自己支持的应用层协议列表给服务器,在服务器的回复中,同样在这个字段制定使用哪种协议。

NPN 和 ALPN 主要不同在于

  • NPN 是服务端发送,客户端选择;ALPN 正好相反。
  • NPN 选择的协议的结果是在 ChangeCipherSpec 之后加密发送的,而 ALPN 是明文发送,也就是说允许网络路径中间的设备查看到协商的结果(允许路由根据不同的结果决定转发?)。

Certificate Transparency

透明证书是指 CA 把它签发的所有证书都提交到一个 log server 上供所有人查询。客户端会收到查询的结果,称为 Singed Ceritificate Timestamp(SCT),在 TLS 扩展中这个 名字叫 signed_certificate_timestamp

Elliptic Curve Capabilities

椭圆曲线兼容。RFC 4492 指明了客户端在 handshake 过程中协商 ECC 的两个扩展名称。elliptic_curve 扩展字段用在 ClientHello 中指明客户端支持的椭圆曲线, 服务端从中选择一个并告知客户端。

这是 RFC4492中定义的椭圆曲线。

        enum {
            sect163k1 (1), sect163r1 (2), sect163r2 (3),
            sect193r1 (4), sect193r2 (5), sect233k1 (6),
            sect233r1 (7), sect239k1 (8), sect283k1 (9),
            sect283r1 (10), sect409k1 (11), sect409r1 (12),
            sect571k1 (13), sect571r1 (14), secp160k1 (15),
            secp160r1 (16), secp160r2 (17), secp192k1 (18),
            secp192r1 (19), secp224k1 (20), secp224r1 (21),
            secp256k1 (22), secp256r1 (23), secp384r1 (24),
            secp521r1 (25),
            reserved (0xFE00..0xFEFF),
            arbitrary_explicit_prime_curves(0xFF01),
            arbitrary_explicit_char2_curves(0xFF02),
            (0xFFFF)
        } NamedCurve

另一个扩展字段是 ec_point_formats 用于压缩椭圆曲线加密的参数,但是用的不多在此也不介绍。

关于椭圆曲线加密,可以参考看雪的这篇文章

Heartbeat

Next Protocol Negotiation

Secure Renegotiation

Server Name Indication

Session Tickets

Signature Algorithms

OCSP Stapling

客户端可以用 status_request 扩展字段指明自己支持 OCSP。服务器可以使用 OCSP Stapling 功能更新证书注销的信息,并推送给客户端。

服务器发现客户端送来的握手消息中包含 status_request 时,如果自己支持这个特性,则在返回的 ServerHello 消息中将status_request 设置为空,并且在发送完 Ceritificate 之后,继续发送 CertificateStatus 消息。

OCSP 设计之初只支持服务器返回的一个 response 消息,客户端用这个消息验证服务器的证书是否有效。在后来的 RFC 6961 中,更新了 status_request_v2 扩展允许多个 OCSP 回复,但是这个功能目前并没有被大多数客户端和服务器支持。


<-- 返回首页