net/http: Transport VerifyHostname w/ TLS currently non optional

[kardianos]

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
Attempt to use the http.Client using the default Transport when
hitting a server who's TLS cert hostname does not match the DNS name.

What is the expected output?
The transport will fail with an error.

What do you see instead?
Optionally allow such a connection to succeed.
(disable the check in http/transport.go:365)

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which revision are you using?  (hg identify)
99ea0887e633+ tip

Please provide any additional information below.
Suggest adding an field in either http.Transport or tls.Config like DisableHostnameCheck.

[rsc]

Comment 1:

i am not sure we need a new variable.  
it could work for http to look at
TLSClientConfig.InsecureSkipVerify.

Owner changed to @bradfitz.

Status changed to Accepted.

[bradfitz]

Comment 2:

This issue was closed by revision 2cab897.

Status changed to Fixed.

[gopherbot]

Comment 3 by jtolds:

Is there any way we can re-open this issue?
I'm working on a distributed system in which none of the hosts have stable
hostnames/IPs/ports. However, we still want to use SSL with both client and server
certificate verification.
Disabling hostname check only when InsecureSkipVerify doesn't do it for us. Is there a
way we can disable the hostname check without setting InsecureSkipVerify?

[gopherbot]

Comment 4 by jtolds:

(Before you worry whether or not my system is vulnerable to MITM attacks, members of
this distributed system are identified by their public key)

[agj32mrgibbits]

Can we please re-open this issue? There should be an option to verify the certificate chain without verifying the hostname.

https://tools.ietf.org/html/rfc6125#appendix-B.2

...
If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted.  (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.)
...

[minux]

Please file a new issue. The problem reported in this issue has been fixed two years ago.

[agj32mrgibbits]

I do not wish to cause a duplicate issue with identical title, identical problem, and identical suggested solution "adding an field in either http.Transport or tls.Config like DisableHostnameCheck".

[minux]

Unless the commit fixing the issue has been rolled back, we generally don't reopen a closed issue.