Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: Transport doesn't verify x509 cert against request.Host #7854

Closed
DanielMorsing opened this issue Apr 24, 2014 · 7 comments
Closed
Milestone

Comments

@DanielMorsing
Copy link
Contributor

Transport only tries to verify the x509 cert against req.URL.Host and doesn't look at
req.Host. This is an issue for those times where you want to dial an IP from a source
different than DNS, but still want to give the correct host name.

Example: http://play.golang.org/p/xP1hnu2kX_
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-go1.4.

@DanielMorsing
Copy link
Contributor Author

Comment 2:

Just realised you can get around this by setting InsecureSkipVerify in tls.Config and
checking Response.TLS after the fact.
We will probably want to verify against Request.Host anyway, since the simple method of
dialling to an IP only works if the host has an IP SAN in their certificate.

@DanielMorsing
Copy link
Contributor Author

Comment 3:

Actually, that won't work, since you're sending potentially sensitive headers before you
can verify that you got to the right server.

@gopherbot
Copy link

Comment 4:

CL https://golang.org/cl/91430044 mentions this issue.

@bradfitz
Copy link
Contributor

Comment 5:

I don't think this is worth the added the complexity. I don't like making the
connectMethodKey larger.
It seems that you really just want a way to control the Transport.Dial phase to connect
to a specific IP when making https requests. Somebody else wanted that too, but I can't
find the bug or email right now. (Something about Transport Dial or DialTLS ...)
In Go 1.3, the URL and Host fields of Request are documented well:
http://golang.org/pkg/net/http/#Request
        // For client requests, the URL's Host specifies the server to
        // connect to, while the Request's Host field optionally
        // specifies the Host header value to send in the HTTP
        // request.
        URL *url.URL
        // For client requests Host optionally overrides the Host
        // header to send. If empty, the Request.Write method uses
        // the value of URL.Host.
        Host string
I don't want to make those more complicated and introduce a new concept of "which
hostname is used for TLS checks".
Feel free to argue otherwise if you can tell me why this is useful or where there's
precedent that we're doing it wrong.

Status changed to WontFix.

@DanielMorsing
Copy link
Contributor Author

Comment 6:

The problem that triggered this issue is in a WAN optimization tool we've written.
It consists of 2 parts, an HTTP server that sits on our edge caches and a HTTP client
that sits on the client network. We get a request on the server, do some magic on the
request and then send it to the client.
On the client end, we convert the request it into the original form and send the it to
the origin server.
The problem comes when we need to use TLS to reach the origin HTTP server. We can't rely
on the original hostname (it points to our edge caches), so we send along a hostname for
the backend with the request and then dial to that instead. Since the customer has set
up their certs to their public name, the verification fails. 
We've worked around this for now by encoding the information in the req.URL.Host string,
but it is a really ugly hack.
You're right in that this is more about wanting control over the dial step than the
verification step, but the dial function cannot get to the information that it needs to
do this trick. Ideally, I want to add a couple of parameters to the dial function, but
can't do that because of go1 compatibility.

@bradfitz
Copy link
Contributor

Comment 7:

But we could add a new hook.
I still can't find the original thread about others wanting that hook. Perhaps you can
stir up some noise on a mailing list and try to find the other party.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants