Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses

["Laszlo Ersek" <lersek@redhat.com>]

Here's an extra point:

On 10/16/19 09:36, Laszlo Ersek wrote:
> On 10/16/19 07:18, Wu, Jiaxin wrote:

>> Fortunately, I get my wanted answer in RFC6125, SECTION 3.1 :
>>
>>    If a subjectAltName extension of type dNSName is present, that MUST
>>    be used as the identity.  Otherwise, the (most specific) Common
>>    Name field in the Subject field of the certificate MUST be used.
>>    Although the use of the Common Name is existing practice, it is
>>    deprecated and Certification Authorities are encouraged to use the
>>    dNSName instead.
>>    ...
>>    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.
> 
> Wow!
> 
> This seems to prove David right, and it suggests that symptom (2)
> encountered with my patch is actually *valid* behavior -- the
> certificate I generated with "genkey" is *not* valid for a URI that
> specifies an IP address!
> 
> This is not good news: the "curl" utility also accepts such a
> certificate as valid (IP address in URL, but the certificate only
> contains a CN,  matching the IP address in textual form). Is that a bug
> in "curl" then?

Check this out:

https://wiki.openssl.org/index.php/Hostname_validation

(The latest version of the article, which I'm looking at now, is
<https://wiki.openssl.org/index.php?title=Hostname_validation&oldid=2665>.)

This wiki article on the openssl website explains how to do hostname
validation, and it also quotes "curl" code.

Notice that it does not consider IP address validation specifically. The
example code for OpenSSL 1.1.0 only calls SSL_set1_host().

And, the code quoted from "curl" seems to suffer from two issues:

- matches_subject_alternative_name() ignores GEN_IP -- it only compares
the host part of the URL against GEN_DNS entries

- if matches_subject_alternative_name() fails, matches_common_name() can
still accept the certificate, even if the URL specified a numeric IP
address.

How are we supposed to get this right if even the reference code in the
wiki appears wrong (per RFC6125)?

Anyway: once David's PR#9201 is merged into OpenSSL, the example code in
the wiki page that calls SSL_set1_host() will become right.

Thanks
Laszlo