You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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
assignee='https://github.com/tiran'closed_at=<Date2017-11-26.22:33:13.727>created_at=<Date2014-12-11.21:03:43.418>labels= ['type-security', 'expert-SSL', '3.7']
title='Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling.'updated_at=<Date2017-11-26.22:33:13.726>user='https://github.com/dstufft'
Various browsers are dropping support for wild card certificates which are anything but a single "*" alone in the left most position. The other style wildcards were deprecated previously and they should not appear in any public certificate and in the words of the Chrome project are "dang weird for internal certificates".
I believe we should follow suite and just only allow a single "*" alone in the left most segment for the SSL handling code.
As a part of this, we might want to consider changing the implementation to not compile the SANs into a regular expression. Constantly compiling new regexs can cause churn in the re cache, which can degrade performance -- also, it's probably much worse on PyPy :-)
are you ok with a backport to 2.7 and 3.6? Substring (aka partial) matching of wildcards is a MAY feature according to RFC 6125 https://tools.ietf.org/html/rfc6125#section-6.4.3 . They are a violation of CA/B Form's baseline requirements, so no publicaly trusted cert may contain a CN or SAN entry with a partial wildcard. Several libraries and languages do not implement the feature either. Improper wildcard matching caused a bunch of security issues and CVEs in Python.