服务器hello中意外的TLS扩展应答

Question

当服务器hello包含TLS扩展的意外响应(例如ALPN)时，预期的行为是什么？

我应该(作为客户端)终止连接还是忽略扩展？它是否在RFC中定义？对于不同的扩展，行为是否应该有所不同？

Answer 1

在TLS 1.2 RFC部分7.4.1.4中，它说：

除非在相应的ServerHello中出现相同的扩展类型，否则扩展类型不能出现在ClientHello中。如果客户端在ServerHello中接收到它在关联的ClientHello中未请求的扩展类型，则必须使用unsupported_extension致命警报中止握手。

对于TLSv1和TLSv1.1，请参阅RFC 3546，这两个版本都适用。

第2.3节：

注意，对于所有扩展类型(包括将来定义的扩展类型)，扩展类型不能出现在扩展服务器hello中，除非在相应的客户机hello中出现相同的扩展类型。因此，如果客户端接收到扩展服务器hello中的扩展类型，而它们在关联的(扩展的)客户机hello中没有请求，则必须中止握手。

第4节:错误警报

"unsupported_extension“--此警报是由接收扩展服务器hello的客户端发送的，该扩展服务器hello包含他们没有在相应的客户端hello中放置的扩展(参见2.3节)。这个信息总是致命的。

Answer 2

当服务器hello包含TLS扩展的意外响应(例如ALPN)时，预期的行为是什么？

我想，当您说“意外的答复”时，您是在建议服务器使用一个ALPN "selected“值进行响应，而这个值并不属于客户端建议的值。

我应该(作为客户端)终止连接还是忽略扩展？它是否在RFC中定义？

虽然RFC 7301不是显式的，但我认为隐含的期望是客户机应该终止TLS握手--就像服务器不支持客户机所宣传的任何协议一样：

In the event that the server supports no protocols that
the client advertises, then the server SHALL respond
with a fatal "no_application_protocol" alert.

对于不同的扩展，行为是否应该有所不同？

不同的扩展可能以不同的方式处理这种情况--两个最常见的处理程序是“中止握手”和“忽略扩展尝试”。从本质上看，扩展通常能够容忍不同级别的支持和实现成熟度。