match_hostname treats SAN IP address as DNS name and fails to check CN then

[noxxi]

BPO	28938
Nosy	@tiran, @alex, @dstufft, @Lukasa, @jay

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tiran'
closed_at = <Date 2017-09-05.22:39:36.877>
created_at = <Date 2016-12-11.20:14:26.505>
labels = ['expert-SSL', 'type-bug', '3.7', 'invalid']
title = 'match_hostname treats SAN IP address as DNS name and fails to check CN then'
updated_at = <Date 2017-09-05.22:39:36.876>
user = 'https://bugs.python.org/noxxi'

bugs.python.org fields:

activity = <Date 2017-09-05.22:39:36.876>
actor = 'christian.heimes'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2017-09-05.22:39:36.877>
closer = 'christian.heimes'
components = ['SSL']
creation = <Date 2016-12-11.20:14:26.505>
creator = 'noxxi'
dependencies = []
files = []
hgrepos = []
issue_num = 28938
keywords = []
message_count = 5.0
messages = ['282940', '282945', '282950', '301387', '301388']
nosy_count = 7.0
nosy_names = ['janssen', 'christian.heimes', 'alex', 'dstufft', 'Lukasa', 'noxxi', 'raysatiro']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue28938'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']

[noxxi]

from Lib/ssl.py

303 elif key == 'IP Address':
304 if host_ip is not None and _ipaddress_match(value, host_ip):
305 return
306 dnsnames.append(value)
307 if not dnsnames:
308 # The subject is only checked when there is no dNSName entry
309 # in subjectAltName

RFC 2818 and RFC 6125 say that CN should not be used if subjectAltNames contains DNS names. This means CN should still be checked if SAN contains only IP addresses. By appending IP address to dnsnames in line 306 it will not check the CN if there are no DNS names in SAN but only IP address.

See also http://stackoverflow.com/questions/41089539/authentication-issue-with-ssl-certificate-using-python-requests-lib/41090559#41090559

[tiran]

Python's implementation of host name verification conforms to RFC 6125, section 6.4.4. The CN check is optional (MAY). Python treats the presence of an IP Address as indicator that CN check should not be performed.

In fact hostname verification code should be more strict and not fall back to CN when a SRV-ID or URI is present. But the ssl module lacks support to fetch SRV-ID, see bpo-28191. Since public CAs and members of the CAB forum are not yet allowed to issue certificates with SRV-ID, it's not a security issue.

https://tools.ietf.org/html/rfc6125#section-6.4.4

6.4.4. Checking of Common Names

As noted, 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.

Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID).

[noxxi]

On Sun, Dec 11, 2016 at 08:26:32PM +0000, Christian Heimes <report@bugs.python.org> wrote:

Christian Heimes added the comment:

Python's implementation of host name verification conforms to RFC 6125, section 6.4.4. The CN check is optional (MAY). Python treats the presence of an IP Address as indicator that CN check should not be performed.

RFC 6125 does not obsolete RFC 2818. In fact it says in section 1.4:

This document also does not supersede the rules for verifying service
identity provided in specifications for existing application
protocols published prior to this document, such as those excerpted
under Appendix B...

Where Appendix B.2 explicitly cites the relevant parts from RFC 2818 like this
in 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.

Thus while RFC 6125 might say MAY for checking the CN the more specific RFC
2818 says clearly MUST. Also, the intention of RFC 6125 in 6.4.4 is in my
opinion to distinguish between applications never checking the CN and
applications which check the CN, while addressing the last ones that CN
should not be checked for specific SAN record types. iPAddress is not a type
which is considered for this special treatment.

Regards,
Steffen

[tiran]

I don't like to change the behavior of match_hostname(). RFC 2818 is deprecated. Recent browsers are no longer using CN to verify hostnames. Python is going to ignore CN soonish, too.

[alex]

+1 Christian, we should not be expanding our usage of CNs at all.