This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes
Date 2016-09-18.11:13:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1474197180.9.0.848250707653.issue28196@psf.upfronthosting.co.za>
In-reply-to
Content
The ssl.match_hostname() function does not conform to RFC 6125 because it can fall back to Subject CN when a cert has no dNSName SAN (subject alternative name) but a SRVName otherName SAN or URI SAN.

---
https://tools.ietf.org/search/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.
---

For now it's not a security problem because no public CA in the CA/Browser Forum is allowed to issue certs with SRV-ID or URI-ID. I checked a couple of libraries and browers. OpenSSL, NSS/Firefox, GnuTLS, embedtls (Polar) and libcurl don't check for the present of SRV-ID or URI-ID either. Only Hynek's service_identity package follows the RFC to the letter. #28191 adds the ability to fetch SRV-ID entries.
History
Date User Action Args
2016-09-18 11:13:00christian.heimessetrecipients: + christian.heimes
2016-09-18 11:13:00christian.heimessetmessageid: <1474197180.9.0.848250707653.issue28196@psf.upfronthosting.co.za>
2016-09-18 11:13:00christian.heimeslinkissue28196 messages
2016-09-18 11:13:00christian.heimescreate