Issue 28938: match_hostname treats SAN IP address as DNS name and fails to check CN then (original) (raw)
Created on 2016-12-11 20:14 by noxxi, last changed 2022-04-11 14:58 by admin. This issue is now closed.
Messages (5)
Author: Steffen Ullrich (noxxi)
Date: 2016-12-11 20:14
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.
Author: Christian Heimes (christian.heimes) * 
Date: 2016-12-11 20:26
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 #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).
Author: Steffen Ullrich (noxxi)
Date: 2016-12-11 21:39
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
Author: Christian Heimes (christian.heimes) *
Date: 2017-09-05 22:34
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.
Author: Alex Gaynor (alex) *
Date: 2017-09-05 22:37
+1 Christian, we should not be expanding our usage of CNs at all.
History
Date
User
Action
Args
2022-04-11 14:58:40
admin
set
github: 73124
2017-09-05 22:39:36
christian.heimes
set
status: open -> closed
stage: resolved
2017-09-05 22:37:42
alex
set
status: pending -> open
messages: +
2017-09-05 22:34:52
christian.heimes
set
status: open -> pending
type: behavior
messages: +
versions: + Python 2.7, - Python 3.3, Python 3.4, Python 3.5
2016-12-11 23:50:58
raysatiro
set
nosy: + raysatiro
2016-12-11 21:39:39
noxxi
set
messages: +
2016-12-11 20:57:41
Lukasa
set
status: pending -> open
nosy: + Lukasa
2016-12-11 20:26:32
christian.heimes
set
status: open -> pending
messages: +
assignee: christian.heimes
components: + SSL
resolution: not a bug
2016-12-11 20:15:32
ned.deily
set
nosy: + janssen, christian.heimes, alex, dstufft
2016-12-11 20:14:26
noxxi
create