➜
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.
Created on 2016-09-18 11:13 by christian.heimes, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Messages (2) | |||
|---|---|---|---|
| msg276882 - (view) | Author: Christian Heimes (christian.heimes) *  |
Date: 2016-09-18 11:13 | |
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. |
|||
| msg301501 - (view) | Author: Christian Heimes (christian.heimes) * |
Date: 2017-09-06 19:27 | |
Let OpenSSL handle this in the future. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:37 | admin | set | github: 72383 |
| 2017-09-06 19:27:52 | christian.heimes | set | status: open -> closed resolution: wont fix messages: + msg301501 stage: test needed -> resolved |
| 2016-09-18 11:13:07 | christian.heimes | set | dependencies: + Support RFC4985 SRVName in SAN name |
| 2016-09-18 11:13:00 | christian.heimes | create | |