-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
crypto/tls: default tls.Config does not seem to verify the server certificate matches the hostname #7342
Labels
Milestone
Comments
Adam? Owner changed to @agl. Status changed to Accepted. |
The certificates will still be verified when no hostname is provided, but they won't be checked against any hostname. However, when using tls.Dial, the hostname will be taken from the server's address if none is given in the tls.Config. So generally things will Just Work. Only if tls.Client is used directly and no hostname is given can there be a problem. Obviously, if a hostname isn't given anywhere then there's nothing that *can* be matched against and the user of low-level interfaces like that has to take care of it. Perhaps it should have been a fatal error, but I don't believe that we can break backwards compatibility. There would also then be the question of how to support code that does want to do the checking itself (i.e. because it wants to match iOS which I still believe has non-standard wildcard support.) So I think this is WaI. tls.Dial should do what you want without surprises. Status changed to WorkingAsIntended. |
This issue was closed by revision fca335e. Status changed to Fixed. |
FiloSottile
pushed a commit
to FiloSottile/go
that referenced
this issue
Oct 12, 2018
…iven. crypto/tls has two functions for creating a client connection: Dial, which most users are expected to use, and Client, which is the lower-level API. Dial does what you expect: it gives you a secure connection to the host that you specify and the majority of users of crypto/tls appear to work fine with it. Client gives more control but needs more care. Specifically, if it wasn't given a server name in the tls.Config then it didn't check that the server's certificates match any hostname - because it doesn't have one to check against. It was assumed that users of the low-level API call VerifyHostname on the certificate themselves if they didn't supply a hostname. A review of the uses of Client both within Google and in a couple of external libraries has shown that nearly all of them got this wrong. Thus, this change enforces that either a ServerName or InsecureSkipVerify is given. This does not affect tls.Dial. See discussion at https://groups.google.com/d/msg/golang-nuts/4vnt7NdLvVU/b1SJ4u0ikb0J. Fixes golang#7342. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/67010043
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by willchan@chromium.org:
The text was updated successfully, but these errors were encountered: