diff options
author | Adam Langley <agl@golang.org> | 2014-02-21 15:56:41 -0500 |
---|---|---|
committer | Adam Langley <agl@golang.org> | 2014-02-21 15:56:41 -0500 |
commit | 696b0b7174ac6ee40493037b4e96ea80e1607482 (patch) | |
tree | 17c7a8d9049164d30429cfb3a9284c0712e152e0 /test/fixedbugs/bug152.go | |
parent | 517ee5cd6819ba6cd96b5c0a59bfbb17f35a26fb (diff) | |
download | go-696b0b7174ac6ee40493037b4e96ea80e1607482.tar.gz |
crypto/tls: enforce that either ServerName or InsecureSkipVerify be given.
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 issue 7342.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/67010043
Diffstat (limited to 'test/fixedbugs/bug152.go')
0 files changed, 0 insertions, 0 deletions