crypto/tls: set TLSPlaintext.version to MinVersion

[riraccuia]

In its current state, the crypto/tls package does not allow an implementer to choose whether a TLS 1.2 client should present the same TLS version (0x0303) in either record and handshake layers of the ClientHello message.

The current default behavior just sets the version in the record layer to 1.0 to maintain compatibility with legacy/buggy TLS server implementations.

This problem is described in RFC 5246 Appendix E.1

This may apply to TLS 1.1 as well

@FiloSottile @bradfitz

[FiloSottile]

Apologies for responding to #31079 before seeing this.

I still don't see the compelling use case for this config option. I'm aware of no servers that require 0x0303 as the protocol version, which would be off-spec behavior.

When we have the option to select a default that works for everyone, we always prefer it to exposing a config option and delegating the complexity and learning requirement to the application.

[dmagyar]

In our use-case an IPS is blocking negotiation when attempted at <TLS1.2. Being a network appliance this decision is made by observing ClientHello and therefore even if I set MinVersion to 1.2 I'm getting blocked. Understand that the default works for most use-cases but there could be edge cases where a proper version in ClientHello is required. All modern browsers adhere to proper TLS versions, so far the only issue I had is with Golangs' TLS :(

[FiloSottile]

If the IPS is abusing TLSPlaintext.version as a sort of minimum supported version, it is not compliant with RFC 5246. From Section E.1:

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

I don't know what you mean about browsers, but my Chrome instance sends 0x0301 as TLSPlaintext.version. I suppose we could set it to tls.Config.MinVersion, rather than make it configurable, if that's what you need.

[dmagyar]

I would love that too. If MinVersion is not set then default to current behavior.