Skip to content
Snippets Groups Projects
  • Daniel McCarney's avatar
    e282cbb1
    crypto/tls: handle client hello version too high · e282cbb1
    Daniel McCarney authored
    If the client hello legacy version is >= TLS 1.3, and no
    supported_versions extension is sent, negotiate TLS 1.2 or lower when
    supported.
    
    On the topic of supported version negotiation RFC 8446 4.2.1 indicates
    TLS 1.3 implementations MUST send a supported_versions extension with
    a list of their supported protocol versions. The crypto/tls package
    enforces this when the client hello legacy version indicates TLS 1.3
    (0x0304), aborting the handshake with an alertMissingExtension alert if
    no supported_versions were received.
    
    However, section 4.2.1 indicates different behaviour should be used when
    the extension is not present and TLS 1.2 or prior are supported:
    
      If this extension is not present, servers which are compliant with
      this specification and which also support TLS 1.2 MUST negotiate
      TLS 1.2 or prior as specified in [RFC5246], even if
      ClientHello.legacy_version is 0x0304 or later.
    
    This commit updates the client hello processing logic to allow this
    behaviour. If no supported_versions extension was received we ignore the
    legacy version being >= TLS 1.3 and instead negotiate a lower supported
    version if the server configuration allows.
    
    This fix in turn allows enabling the BoGo ClientHelloVersionTooHigh,
    MinorVersionTolerance, and MajorVersionTolerance tests.
    
    Updates #72006
    Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c9
    Reviewed-on: https://go-review.googlesource.com/c/go/+/671235
    
    
    Reviewed-by: default avatarCherry Mui <cherryyz@google.com>
    Reviewed-by: default avatarRoland Shoemaker <roland@golang.org>
    LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
    e282cbb1
    History
    crypto/tls: handle client hello version too high
    Daniel McCarney authored
    If the client hello legacy version is >= TLS 1.3, and no
    supported_versions extension is sent, negotiate TLS 1.2 or lower when
    supported.
    
    On the topic of supported version negotiation RFC 8446 4.2.1 indicates
    TLS 1.3 implementations MUST send a supported_versions extension with
    a list of their supported protocol versions. The crypto/tls package
    enforces this when the client hello legacy version indicates TLS 1.3
    (0x0304), aborting the handshake with an alertMissingExtension alert if
    no supported_versions were received.
    
    However, section 4.2.1 indicates different behaviour should be used when
    the extension is not present and TLS 1.2 or prior are supported:
    
      If this extension is not present, servers which are compliant with
      this specification and which also support TLS 1.2 MUST negotiate
      TLS 1.2 or prior as specified in [RFC5246], even if
      ClientHello.legacy_version is 0x0304 or later.
    
    This commit updates the client hello processing logic to allow this
    behaviour. If no supported_versions extension was received we ignore the
    legacy version being >= TLS 1.3 and instead negotiate a lower supported
    version if the server configuration allows.
    
    This fix in turn allows enabling the BoGo ClientHelloVersionTooHigh,
    MinorVersionTolerance, and MajorVersionTolerance tests.
    
    Updates #72006
    Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c9
    Reviewed-on: https://go-review.googlesource.com/c/go/+/671235
    
    
    Reviewed-by: default avatarCherry Mui <cherryyz@google.com>
    Reviewed-by: default avatarRoland Shoemaker <roland@golang.org>
    LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Code owners
Assign users and groups as approvers for specific file changes. Learn more.