Нарушает ли Server Hello RFC? Кажется, в RFC есть противоречие.
Клиент утверждает, что наше устройство (Citrix Netscaler) возвращает расширение (ec_point_formats: формат точки EC: несжатый), когда он его не запрашивает. Из-за этого они утверждают, что наше устройство не соответствует RFC.
В RFC я нахожу эти два соответствующих раздела: расширения:
см. rfc3546 sec 2.3. Привет расширения
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)
Думаю, ваш клиент прав.
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. Расширение Server Hello дает понять, что ec_point_formats расширение в ServerHello следует отправлять только как ответ на ec_point_formats расширение в ClientHello, т.е. его нельзя отправлять без такого расширения в ClientHello, и, следовательно, ваш сервер ведет себя неправильно:
Когда это расширение отправляется:
Расширение поддерживаемых форматов точек включено в сообщение ServerHello. в ответ на сообщение ClientHello, содержащее расширение поддерживаемых форматов точек при согласовании набора шифров ECC.
Обратите внимание, что похожая проблема, которую вы описываете, похоже, возникает и со старыми версиями балансировщика нагрузки F5, см. Отключить поддерживаемое расширение эллиптических кривых с сервера .