[gnutls-devel] GnuTLS hostname checking bug report

[Nikos Mavrogiannopoulos]

On Thu, Mar 16, 2017 at 5:56 AM, Suphannee Sivakorn
<suphannee at cs.columbia.edu> wrote:
>>> 1. Attempting to match CN when any SubjectAltName identifiers present (RFC 6125)
>>> Section 6.3 of RFC 6125 prohibits clients from attempting to match CN
>>> if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any
>>> application-specific identifier types supported by the client. We
>>> found that GnuTLS violates this requirement. The function
>>> gnutls_x509_crt_check_hostname(2), which supports hostname
>>> verification for hostname and IP address, attempts to match
>>> certificate CN even when there is a subjectAltName identifier
>>> presents, e.g., IP address. However, the library follows the
>>> requirement when subjectAltName DNS presents.
>>
>> That is quite interesting. The actual text of RFC6125 is:
>> "Security Warning: A client MUST NOT seek a match for a reference
>> identifier of CN-ID if the presented identifiers include a DNS-ID,
>> SRV-ID, URI-ID, or any application-specific identifier types
>> supported by the client."
>>
>> My understanding of the text is that, the last part of the sentence
>> implies that the prohibition of falling back to CN-ID matching applies
>> when SRV-ID and URI-ID are supported. Given that gnutls doesn't
>> support SRV-ID or URI-ID matching, it falls back immediately after the
>> DNS-ID is checked. I may be wrong though, and I'm forwarding your
>> message to the gnutls development list for further discussion.
>>
>
> #1. The actual text also includes "or any application-specific
> identifier types". As the function gnutls_x509_crt_check_hostname()
> also supports IP address identifier, we believe that if IP-address/DNS
> in SubjectAltName presents, the check for CN should be skipped.

You are right. I've included such an enhancement in the following patch set.
https://gitlab.com/gnutls/gnutls/merge_requests/314

>>> 4. Matching IPv4 string hostname with subjectAltName DNS
>>> We found that giving IPv4 format string as hostname, GnuTLS attempts
>>> to match this string with DNS attribute in the certificate
>>> subjectAltName when IP address attribute in the certificate
>>> subjectAltName does not match or present. Since RFC 1123 allows the
>>> domain name to be letter or digit, this introduced valid DNS names
>>> which are identical to IP addresses.
>>
>> That is an unfortunate but documented behavior for certain broken
>> situations. See:
>> http://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fcrt_005fcheck_005fhostname2
>>
>> It used to be that the DNS field contained IP addresses in some big
>> PKI deployments. I'd appreciate if you could share your findings on
>> other implementations for that issue, as it would help us decide
>> whether to deprecate that behavior.
> #4. We have included the test for libraries i.e., OpenSSL, GnuTLS,
> MbedTLS, MatrixSSL, JSSE, CPython SSL and applications i.e.,
> HttpClient, cURL (default configuration). So far only GnuTLS, MbedTLS
> and MatrixSSL have this behavior, while others perform the check
> against only IP address in SAN when given IPv4 format string.

Thank you. I think we can plan for its removal then.

regards,
Nikos