☰

TLS 实施/RFC 解释

tag-icon • tag-icon networking ssl rfc netscaler
TLS 实施/RFC 解释

Server Hello 是否违反了 RFC？RFC 中似乎存在矛盾。

一位客户声称我们的设备 (Citrix Netscaler) 返回了扩展 (ec_point_formats: EC point format: uncompressed)，而他们并没有请求。因此，他们声称我们的设备不遵循 RFC。

我从 RFC 中找到以下两个相关部分：扩展：

参见 rfc3546 第 2.3 节。Hello Extensions

   Note that for all extension types (including those defined in
   future), the extension type MUST NOT appear in the extended server
   hello unless the same extension type appeared in the corresponding
   client hello.  Thus clients MUST abort the handshake if they receive
   an extension type in the extended server hello that they did not
   request in the associated (extended) client hello.

rfc 4492 和 8422 第 4 节第 3 段：

   The client MUST NOT include these extensions in the ClientHello
   message if it does not propose any ECC cipher suites.  A client that
   proposes ECC cipher suites may choose not to include these
   extensions.  In this case, the server is free to choose any one of
   the elliptic curves or point formats listed in Section 5.  That
   section also describes the structure and processing of these
   extensions in greater detail.

数据包踪迹：

客户您好：

TLSv1.2 Record Layer: Handshake Protocol: Client Hello
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 63
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 59
        Version: TLS 1.2 (0x0303)
        Random
        Session ID Length: 0
        Cipher Suites Length: 20
        Cipher Suites (10 suites)
        Compression Methods Length: 1
        Compression Methods (1 method)

服务器你好：

TLSv1.2 Record Layer: Handshake Protocol: Server Hello
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 82
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 78
        Version: TLS 1.2 (0x0303)
        Random
        Session ID Length: 32
        Session ID: bfe64de5d94a7c4c12bdb419b6938efcbb70429cd216fa1c...
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Compression Method: null (0)
        Extensions Length: 6
        Extension: ec_point_formats
            Type: ec_point_formats (0x000b)
            Length: 2
            EC point formats Length: 1
            Elliptic curves point formats (1)
                EC point format: uncompressed (0)

答案1

我认为你的客户是对的。

RFC 4492 及其后续 RFC 8422 明确指出，此扩展是对客户端发送的响应ec_point_formats，这意味着如果客户端没有发送，则不应包含此扩展ec_point_formats。相反，如果客户端没有发送任何内容，则ec_point_formats服务器必须假定客户端仅支持未压缩的点格式。事实上，对于 RFC 8422 来说，除了未压缩的点格式之外的所有格式都已过时，因此客户端不包含此扩展是完全没问题的。引用自RFC 8422 5.1.2. 支持的点格式扩展：

本规范弃用了除未压缩点格式之外的所有格式。...出于向后兼容的目的，点格式列表扩展可能 仍应包括在内，且只包含一个值：未压缩的点格式 (0)。RFC 4492 规定如果缺少此扩展，这意味着仅支持未压缩的点格式，因此与支持未压缩格式的实现的互操作性应该可以在有或没有扩展的情况下进行。

和RFC 8422 5.2. 服务器 Hello 扩展明确指出，ec_point_formatsServerHello 中的扩展只能作为对ec_point_formatsClientHello 中的扩展的响应发送，即，如果 ClientHello 中没有这样的扩展，就不应该发送，因此您的服务器行为不正确：

发送此扩展时：
支持的点格式扩展包含在 ServerHello 消息中响应包含支持点格式扩展的 ClientHello 消息在协商 ECC 密码套件时。

请注意，您描述的类似问题似乎也发生在旧版本的 F5 负载均衡器中，请参阅从服务器禁用支持的椭圆曲线扩展 。

相关内容