homepage

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 2017年09月08日.21:04:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
In-reply-to
Content
Python should no longer attempt to verify hostname and ip addresses itself. OpenSSL 1.0.2 and newer is able to verify hostname and IP addresses itself. The new APIs are properly hooked into chain validation step. Hostname matching implements RFC 6125. CN matching and partial wildcards can be tuned with additional. The API is documented here: https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set1_host.html . X509_VERIFY_PARAM_set1_host is available since OpenSSL 1.0.2. LibreSSL 2.5.3+ implement the proper bits and pieces, too.
Why should we use OpenSSL rather than matching hostnames ourselves?
In the past, OpenSSL did not contain any code to perform host name
matching. Application were required to role their own implementation.
This caused code duplication and various security issues, because
it is far from trivial to cover all edge cases. Python had multiple
security issues just caused by incorrect or buggy hostname matching:
* Until Python 3.2 and 2.7.9, the ssl module was not capable of
 performing host name matching. ``ssl.match_hostname()`` was
 introduced in 3.2.0 and later back-ported to 2.7.9.
* Issue #12000: Subject CN was ignored when a subject alternative
 name extension (SAN) was present without dNSName entries, thus
 violating RFC 2818.
* CVE-2013-2099: Multiple wildcard characters could be abused
 for Denial-of-Service attack in the re module.
* Issue #17997: RFC 2818 was superseded by RFC 6125, which no longer
 allows multiple wildcard characters. Wildcards are only supported
 in the left-most label.
* Issue #17997: ``ssl.match_hostname()`` did not implement partial
 wildcards of international domain names correctly.
* Issue #18709: The ssl module used an inappropriate OpenSSL function
 to convert host names from ASN.1 to strings. A host name with an
 embedded NULL byte could be abused to trick validation.
* Issue #17305: The ssl module does not handle IDNA 2008-encoded
 host names correctly. It converts from IDN A-label (ASCII
 compatible encoding) to IDN U-label (unicode) with Python's idna
 encoding, which is IDNA 2003-only.
* Issue #30141: The host name is not verified when a SSLSocket is
 created with ``do_handshake_on_connect=False`` and the application
 causes an implicit handshake w/o calling do_handshake() explicitly.
* A SSLSocket performs host name matching *after* the handshake and
 during the handshake. In case of an invalid host name, a client
 is suppose to abort the connection with appropriate TLS alert.
 This causes two problem. For one the server is not informed about
 a problem with the certificate. Also an invalid host name does not
 prevent the client from sending a TLS client authentication
 cert to a malicious server. The cert typically contains personal
 information like username and department.
History
Date User Action Args
2017年09月08日 21:04:46christian.heimessetrecipients: + christian.heimes
2017年09月08日 21:04:46christian.heimessetmessageid: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
2017年09月08日 21:04:46christian.heimeslinkissue31399 messages
2017年09月08日 21:04:45christian.heimescreate

AltStyle によって変換されたページ (->オリジナル) /