crypto/x509: Wildcard Cerficate Validation Weakness

[gopherbot]

by richmoore44:

Taking a look at the code for certificate verification, the hostname matching function
appears to allow wildcards in IP addresses. I previously reported this issue against FF,
Chrome etc. back in 2010. The code that appears vulnerable can be seen at:
http://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#237

http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt

[agl]

Comment 2:

The Go code ignores IP address SANs, so the '*.2.3.4' form would have to appear in the
CN or as a DNSName SAN.
If the user sets the `hostname' of a TLS connection to the string form of an IP address,
then we will match it against such a wildcard. However, setting the hostname to an IP
address isn't supported.
So I think this bug boils down to "we should try parsing the hostname that the user
asked us to verify as an IP address and fail immediately if it looks like one". Do you
agree?
If, in the future, we support IP addresses like that, we would need to be careful to
match only against IP address SANs, but we don't currently support that at all.

Status changed to WaitingForReply.

[gopherbot]

Comment 3 by richmoore44:

Yes, the fix that I applied for Qt is that if you're asked to connect to an IP address
(IPv4 or IPv6) then do not process wildcards. I believe the FF team took the same
approach.

[gopherbot]

Comment 4 by richmoore44:

I'm unsure why this still has the status waiting for reply. Is there more information
you need?

[agl]

Comment 5:

Indeed, sorry. It's not waiting-for-reply, it's just waiting-for-time. Changed to
"Accepted".

Status changed to Accepted.

[rsc]

Comment 6:

Labels changed: added priority-later, removed priority-triage.

[rsc]

Comment 7:

Status changed to Started.

[bradfitz]

Comment 8:

Note that https://golang.org/cl/7277051/ is effectively a Go 1 API regression,
since it breaks anybody using net/http/httptest's NewTLSServer and trying to test
against it with httptest.(*Server).URL.
Could we keep CL 7277051 but white-list certs using "127.0.0.1" or "[::1]" as subjects? 
That would keep Go 1 users' tests still working.  Is that a security problem for any
reason?

[agl]

Comment 9:

This issue was closed by revision 5b20a18.

Status changed to Fixed.