Home / server / Questions / 952087
Accepted
Leo
Asked: 2019-02-03 21:24:16 +0800 CST

TLS Implementation/RFC interpretation

  • 772

Does the Server Hello break the RFC? There seems to be contradiction in RFC.

A customer claims our device (Citrix Netscaler) returns Extension (ec_point_formats: EC point format: uncompressed) when they do not request it. Because of this they claim our device does not follow the RFCs.

From the RFCs I find these two relevant sections: extensions:

see rfc3546 sec 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 and 8422 sec 4 paragraph 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.

Packet traces:

Client Hello:

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)

Server Hello:

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)
networking

1 Answers

  1. Best Answer

    I think your client is right.

    RFC 4492 and its follow-up RFC 8422 say it quite clear that this extension is a response to a client sending ec_point_formats, which means that it should not be there is the client is not sending ec_point_formats. Instead if the client is not sending any ec_point_formats the server must assume that the client only supports the uncompressed points format. In fact, with RFC 8422 all but uncompressed point format is obsolete so it is perfectly fine for a client to not include this extension. To cite from RFC 8422 5.1.2. Supported Point Formats Extension:

    This specification deprecates all but the uncompressed point format. ... For backwards compatibility purposes, the point format list extension MAY still be included and contain exactly one value: the uncompressed point format (0). RFC 4492 specified that if this extension is missing, it means that only the uncompressed point format is supported, so interoperability with implementations that support the uncompressed format should work with or without the extension.

    And RFC 8422 5.2. Server Hello Extension makes it clear that an ec_point_formats extension in the ServerHello should only be send as a response to an ec_point_formats extension in the ClientHello, i.e. it should not be send without such extension in the ClientHello and thus your server behaves wrong:

    When this extension is sent:
    The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite.

    Note that a similar problem you describe seems to happen also with older versions of F5 load balancer, see Disable Supported Elliptic Curves Extension from server .

    • 4