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
Labels
Milestone
Comments
CL https://golang.org/cl/91430044 mentions this issue. |
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. |
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. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: