Regarding custom TLS verification HTTP error codes

[Daniel Lockhart]

Question regarding crypto/tls. Unfortunately, in the name of supporting legacy hardware,  I need to change the HTTP 400 status code Go returns on a TLS verification failure to something else dynamically, based on the certificate.

https://github.com/golang/go/blob/4ee0df8c466861bcd258ec55b58283f276d3b3d5/src/net/http/server.go#L2070

Is the only option I have to set InsecureSkipVerify to true and rewrite the verification logic within my own TLSConfig.VerifyConnection?

or is there a better way to do this?
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving. 

[Jason E. Aten]

Umm, I don't think you want to set InsecureSkipVerify=true. (I think you need to keep verification on). Otherwise

none of the custom verification callbacks will be called at all, if I'm recalling correctly. 

TLS and HTTP are pretty separate layers; I use TLS alot without HTTP for instance. So it shouldn't be

too difficult to customize a web server's response on TLS handshake fail...

[Jason E. Aten]

Parenthetically, I'm assuming you are talking about implementing your own

VerifyPeerCertificate

or 

VerifyConnection callback

as set in your tls.Config

See https://pkg.go.dev/crypto/tls#Config for reference.

[Daniel Lockhart]

InsecureSkipVerify doesn't affect the callback VerifyConnection, just whether the stdlib TLS verification logic is executed.
I don't like it but I don't see another way to disable the initial HTTP 400 being sent for failed TLS verifications.

The example for VerifyConnection on that same godocs page you link also mentions this.

https://pkg.go.dev/crypto/tls#example-Config-VerifyConnection

[Jason E. Aten]

Yeah, my mistake.

Looks like you might have to provide your own custom net.Listener

by wrapping the standard one.

Gemini suggested this too as a solution, for example: https://go.dev/play/p/l3a4pXA1I75

If the handshake isn't happening, as apparently it happens lazily on 

first read or write of the TLS connection, maybe you can force it to

handshake by reading 0 bytes...