Your Go server sets tls.Config.CipherSuites, yet clients negotiate a suite you excluded. Why?

## The symptom Someone hardens a service: `CipherSuites` is set to a short list of ECDHE AEAD suites, the change is reviewed, the audit item is closed. Weeks later a handshake probe against the running listener reports `TLS_AES_128_GCM_SHA256` — a suite that is not in the list. Nothing is broken and nothing was overridden. The list simply does not apply to the connection that was made. ## Why `tls.Config.CipherSuites` is, in the package's own words, a list of enabled TLS 1.0–1.2 cipher suites, and TLS 1.3 cipher suites are not configurable. TLS 1.3 redefined what a cipher suite names: in TLS 1.2 a suite bundled the key exchange, the authentication algorithm, the bulk cipher and the MAC, which is why there were hundreds of them and why so many were bad. In TLS 1.3 the key exchange and signature are negotiated separately, so a suite names only an AEAD cipher and a hash. Go implements three, all AEAD. There is nothing dangerous in the set, so the package exposes no way to prune it — and once a connection negotiates TLS 1.3, your list is simply not consulted. So the field is not ignored in general. It is ignored *for the connections your modern clients actually make*, which is the worst of both worlds: it works in the test where you forced TLS 1.2, and it is inert in production. ## The related trap `PreferServerCipherSuites` is deprecated and ignored in current Go. crypto/tls decides the suite ordering itself, taking into account whether the machine has hardware AES support, so a server that would be slow at AES prefers ChaCha20. Code that sets this field is expressing an intent the package no longer honours — and, like the suite list, it reads as a control in a review. ## What to do instead Decide what you actually want and pick the matching lever. *I want to guarantee no CBC-mode or otherwise legacy suite can ever be used.* Set `MinVersion: tls.VersionTLS13`. Then the only suites available are the three AEAD ones and the question disappears. The cost is that every client must speak TLS 1.3. *I must keep TLS 1.2 for some clients but want to constrain those connections.* Keep `MinVersion: tls.VersionTLS12` and set `CipherSuites` to the AEAD ECDHE suites you accept. Write a comment saying, in one line, that the list governs TLS 1.2 only — otherwise the next reader re-derives this whole page. `tls.CipherSuites()` returns the suites the package currently implements and considers safe, and `tls.InsecureCipherSuites()` returns the ones it keeps only for compatibility, which is a better basis for a list than a copy-pasted constant block that rots. *I want a report of what is really happening.* Probe it. ```go conn, err := tls.Dial("tcp", "svc.internal:8443", nil) if err != nil { log.Fatal(err) } defer conn.Close() st := conn.ConnectionState() fmt.Println(tls.VersionName(st.Version), tls.CipherSuiteName(st.CipherSuite)) ``` `ConnectionState` reports what the handshake agreed; `VersionName` and `CipherSuiteName` turn the opaque `uint16` values into the names you can paste into a ticket. Run it from a job against every listener you own and you have the fleet's real posture instead of its configured one. From inside a handler, `r.TLS` carries the same `ConnectionState` for the current request, so logging the negotiated version and suite is a one-liner if you would rather sample continuously. ## The reviewing lesson The generalisable point is not about cipher suites. It is that a security setting is a claim, and a claim needs evidence. A field that is silently inapplicable produces no error, no warning and no log line; the only thing that distinguishes it from a working control is an observation of the running system. When a review adds a TLS field, the reviewable artefact is the probe output, not the diff.