@FiloSottile requested issue #49126 to be considered for backport to the next 1.18 minor release.
Interestingly, this is only hit when using the Windows TLS1_3_CLIENT (or a different client that omits the extension) to reach a TLS 1.2-only Go server, because the extension is ignored entirely when negotiating TLS 1.3. This probably explains why it was only noticed for test sites (#49126 (comment)) which might disable TLS 1.3 to test for vulnerabilities, and why it didn't cause widespread breakage.
Still, considering the duplicates that were filed, the fact that we're the odd one out in getting this wrong, the fact that we're off-spec, the fact that this is not something applications can workaround (unless they can upgrade to TLS 1.3), how this kind of issue tends to add complexity to the ecosystem in the form of workarounds, and the simplicity of the fix, I think we should backport it.
PR #49127 / CL 358116 is an incomplete fix because we should not send the extension back when the client didn't send it. I'll send a new fix in a second.
@gopherbot please open backport issues for both supported releases.
@FiloSottile requested issue #49126 to be considered for backport to the next 1.18 minor release.