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 DK26
Recipients DK26, christian.heimes
Date 2019-08-14.13:37:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>

Judging by your comment, I think there is a an unfortnate misunderstanding.

If you'd be kind enough, please let me explain:

1. The issue I had was indeed on Python 3.7, using the highly used
"requests" library. Also my change was -not- applied on the deprecated
but on _dnsname_match() which is a method of another inner class.
My point is that it's still releveant.

2. Although there is a thin line here, it is not a configuration issue by
its classic meaning. It's an outside condition in a production environment
that unpatches Python code cannot handle and thus implicating that Python
is less stable and mistake tolerant than C# and Java (those are the other
more used languages in the company which weren't effected by this problem
-- for some who wouldn't bother like me to patch python source code, this
could be a deal breaker to move to another language).

3. It's a very simple fix that only removes white spaces (empty chars) from
start and end of the DNS before applying all the other tests on it. In fact
by assuring the input of the DNS name, our code becomes -more- secure. In
current state, a missed type DNS name encoded in the certifications could
cause unknowingly Python deamons to stop transmiting data. Also as humans
tend to make such naive errors, a mallicious party could make an attack be
seemless and  be discarded as human error. And if that doesn't convince
you, we can say at the very least the service we provide with our App
becomes unusable and unavailable to clients and for some that could cost
time and money and Python may take the blame as unreliable as compared to
other languages.

4. The thrown exception can be misleading: The exception says that the
problem is a partial wildcard. However the problem is white spaces which
can be difficult to spot. White spaces cannot be part of DNS names thus it
makes no sense to ackonwledge them or refer to them or event test them as
any other legit legal char. Also this is unpredictible to the programmer as
he wouldn't think such a basic trim/strip of white spaces wouldn't happen
in the core of the SSL code what's worse, it can't be handled conventialy
with catching the exception. While a programmer can edit Python source code
to it's needs,  they really shouldn't mess with it for more than a short
term use. Declining the change dooms me for example to always add this
change to projects using SSL.

Thank you for your time.
I truely hope we can resolve this.

On Wed, Aug 14, 2019, 08:09 Christian Heimes <> wrote:

> Christian Heimes <> added the comment:
> This is not a bug in Python but a misconfiguration on your side. A
> workaround for a misconfiguration doesn't belong into upstream code. The
> certificate validation code is security-sensitive and I don't feel
> comfortable to add unnecessary string transformation to it. The code
> refuses bad wildcards because we have had more than one CVE related to
> wildcard matching.
> Besides the ssl.match_hostname() function is deprecated and no longer
> used. Starting with Python 3.7 the ssl module uses OpenSSL to verify host
> names.
> I suggest that you either ship this fix locally with your app. Or talk to
> IT again and have them replace the wrong certificate with a correct one
> that does not violate the standards.
> ----------
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2019-08-14 13:37:44DK26setrecipients: + DK26, christian.heimes
2019-08-14 13:37:44DK26linkissue37845 messages
2019-08-14 13:37:44DK26create