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... On Monday, August 11, 2025 at 3:45:42 PM UTC+1 Daniel Lockhart wrote: > > 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 > > > On Sunday, August 10, 2025 at 6:14:41 PM UTC-4 Jason E. Aten wrote: > > 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. > > On Sunday, August 10, 2025 at 11:06:47 PM UTC+1 Jason E. Aten wrote: > > 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... > > On Tuesday, August 5, 2025 at 10:10:10 PM UTC+1 Daniel Lockhart wrote: > > 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. > > > 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. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/791475ca-e8a9-4c51-bfae-5839d3568136n%40googlegroups.com.
