summaryrefslogtreecommitdiff
path: root/test/fixedbugs/bug152.go
diff options
context:
space:
mode:
authorAdam Langley <agl@golang.org>2014-02-21 15:56:41 -0500
committerAdam Langley <agl@golang.org>2014-02-21 15:56:41 -0500
commit696b0b7174ac6ee40493037b4e96ea80e1607482 (patch)
tree17c7a8d9049164d30429cfb3a9284c0712e152e0 /test/fixedbugs/bug152.go
parent517ee5cd6819ba6cd96b5c0a59bfbb17f35a26fb (diff)
downloadgo-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