IP address wildcard certificate validation

VULNERABILITY

RFC 2818 covers the requirements for matching Common Names (CNs) and
subjectAltNames in order to establish valid SSL connections. It first
discusses CNs that are for hostnames, and the rules for wildcards in this
case. The next paragraph in the RFC then discusses CNs that are IP
addresses:

'In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present in the
certificate and must exactly match the IP in the URI.'

The intention of the RFC is clear in that you should not be able to use
wildcards with IP addresses (in order to avoid the ability to perform
man-in-the-middle attacks). Unfortunately libcurl fails to adhere to this
rule under certain conditions, and subsequently it would allow and use a
wildcard match specified in the CN field.

Exploiting this flaw, a malicious server could participate in a MITM attack
or just easier fool users that it is a legitimate site for whatever purpose,
when it actually isn't.

A good CA should refuse to issue a certificate with the CN as indicated,
however there only need be one CA to issue one in error for this issue to
result in the user getting no warning at all and being vulnerable to MITM.

This flaw is only present in libcurl when built to use one out of a few
specific TLS libraries: OpenSSL, axtls, qsossl or gskit.