crypto/tls: mention in the InsecureSkipVerify docs that it's ok to use with Verify callbacks

[ZhenLian]

Hi Go team,

Our teams(security team and gRPC-Go team) are working on a project that might need to set the field 'InsecureSkipVerify' to true to enable 'VerfiyPeerCertificate' in tls.config. However, according to the comments,

This should be used only for testing.

we are a bit hesitant to set InsecureSkipVerify to true, since it is going to be used in production code. So my questions are:

1. if we set InsecureSkipVerify to true but provide proper endpoint verification mechanisms other than the default hostname check, can it be used in the real environment?

2. If the answer to the first question is "yes", can we improve the comments a little bit? If that's the case, "used only for testing" might be a bit misleading.

Thank you so much for the help!

@FiloSottile

[easwars]

Also, would it make sense for the tls package to allow overriding only the hostname check?

That way, the tls package could still verify the cert chain provided by the peer, but could let the user do custom hostname checks like verifying that the hostname in the peer cert matches a list of acceptable host names or if it matches a wildcard SPIFFE id.

This could be similar to how the user can specify client certificates. They can either provide them upfront with the Certificates field of tls.Config or they can set the GetClientCertificate function which will be invoked at handshake time.

Similarly, we currently have ServerName which the user can specify upfront to check the hostname on the peer cert. If we also had something like CheckServerName(leaf *x509.Certificate) bool, user could provide custom server name checks.

[FiloSottile]

Ah, yes, the docs should be a little less categorical. If you set VerifyPeerCertificate you are fine to set InsecureSkipVerify (but should still be careful because you are without a parachute if your VerifyPeerCertificate is wrong).

Once you need to customize verification, there are too many different needs, so I prefer not to add a callback for each of them. Instead, in Go 1.15 we are adding an easier to use VerifyConnection callback (#36736). I'll drop in an example of how changing name verification is pretty easy with it.

[gopherbot]

Change https://golang.org/cl/239746 mentions this issue: crypto/tls: relax the docs of InsecureSkipVerify