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)
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
.
No comments:
Post a Comment