Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcrypto/tls, net/http: HTTPS + IPv6 literal == bogus SNI #14404
Closed
Labels
Milestone
Comments
willmo
changed the title
This comment has been minimized.
This comment has been minimized.
|
CL https://golang.org/cl/19704 mentions this issue. |
FiloSottile
pushed a commit
to FiloSottile/go
that referenced
this issue
Oct 12, 2018
This is a followup change to golang#13111 for filtering out IPv6 literals and absolute FQDNs from being as the SNI values. Updates golang#13111. Fixes golang#14404. Change-Id: I09ab8d2a9153d9a92147e57ca141f2e97ddcef6e Reviewed-on: https://go-review.googlesource.com/19704 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
FiloSottile
pushed a commit
to FiloSottile/go
that referenced
this issue
Oct 12, 2018
This is a followup change to golang#13111 for filtering out IPv6 literals and absolute FQDNs from being as the SNI values. Updates golang#13111. Fixes golang#14404. Change-Id: I09ab8d2a9153d9a92147e57ca141f2e97ddcef6e Reviewed-on: https://go-review.googlesource.com/19704 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Following up #13111, in Go 1.6 the SNI is still incorrectly sent when using IPv6 literals with HTTPS. HTTP encloses IPv6 literals in square brackets, but when tls prepares to send the SNI it uses net.ParseIP to check for address literals, and that doesn't know about square brackets. Hence the bracket-enclosed literal ends up being sent as the SNI.
I'm not sure if tls should handle square brackets (like x509.Certificate.VerifyHostname does), or if http should strip the brackets before setting ServerName (i.e. in tlsHost()), or what.