What does tls.Config.MinVersion control, and what applies when you leave it at zero?

## What the field means `tls.Config.MinVersion` is a `uint16` naming the oldest protocol version this side will accept. Its counterpart `MaxVersion` names the newest. During a handshake the two peers agree on the highest version both support; if that number falls below your `MinVersion`, the handshake is aborted and the connection is closed. There is no downgrade, no "insecure but connected" state, and no callback that lets you wave one through. That is deliberate — protocol downgrade is exactly the behaviour TLS hardening exists to prevent. The constants are `tls.VersionTLS10`, `tls.VersionTLS11`, `tls.VersionTLS12` and `tls.VersionTLS13`. They are opaque numbers; compare and assign, never arithmetic. ## The zero value is not "no minimum" The single most common misconception is that leaving `MinVersion` unset means anything goes. It does not. Zero means "the package chooses", and the package's choice in current Go is TLS 1.2 for both servers and clients. So an unconfigured `&tls.Config{}` today is already reasonably safe. The trap is a different one: that default is a moving target. Earlier Go releases would happily negotiate TLS 1.0, and the default minimum has been raised more than once. Code that never states its floor therefore behaves differently depending on which toolchain built it, which is uncomfortable when the floor is the thing an auditor asks about. If you have a stated requirement, state it in the code: ```go srv.TLSConfig = &tls.Config{MinVersion: tls.VersionTLS12} ``` That line costs nothing and turns a toolchain-dependent behaviour into a compiled-in fact. It is also the line a reviewer can find with a grep, which matters more than it sounds. ## Driving it from configuration A service that must differ per environment usually maps a config file field onto the constant at startup, validating as it goes: ```go var minVer uint16 switch cfg.MinTLS { case "1.3": minVer = tls.VersionTLS13 case "1.2": minVer = tls.VersionTLS12 default: return fmt.Errorf("unsupported min_tls %q", cfg.MinTLS) } srv.TLSConfig = &tls.Config{MinVersion: minVer} ``` The `default` branch matters. A config parser that silently leaves the variable at zero on a typo hands you the package default while the config file claims something stricter — a setting that reads as enforced and is not. ## MaxVersion `MaxVersion` defaults to the newest version the package implements, TLS 1.3 in current Go. Setting it is almost always wrong: it freezes you below whatever comes next and, in the short term, it drops you back to the TLS 1.2 handshake. The legitimate uses are narrow — reproducing a bug, or working around a middlebox that mangles a newer handshake — and both should be temporary and commented as such. ## Both directions, not just the listener `MinVersion` is a `tls.Config` field, and `tls.Config` is used identically on both sides. A service that hardens `http.Server.TLSConfig` and leaves its outbound `http.Transport.TLSClientConfig` nil has hardened half of itself. Reviewers who only check the listener miss this constantly; if the policy is a fleet policy, it belongs in whatever constructs your HTTP clients too. ## Verifying it rather than believing it The field is easy to set and easy to set somewhere that never runs. Two checks are worth wiring up. Inside a handler, `r.TLS.Version` reports what the current request actually negotiated, which makes it cheap to log the real distribution before you raise a floor. From outside, dial the running listener with a client config whose `MaxVersion` is pinned to the version you claim to reject, and assert the handshake fails; that is a three-line test and it is the only evidence that the floor is real in the deployed binary rather than in the branch you meant to deploy. ## Interaction with cipher suites Raising `MinVersion` to `tls.VersionTLS13` has a side effect people find surprising: it makes `tls.Config.CipherSuites` completely inert, because that field only ever applied to TLS 1.0 through 1.2 and Go does not expose the TLS 1.3 suites for configuration. That is not a bug to work around — every suite TLS 1.3 defines is already an AEAD suite — but it does mean a hardened suite list and a 1.3 floor are alternatives, not a belt-and-braces pair.