David K. <dikave...@gmail.com> added the comment:
OK, I see your point :) Modification of the original certificiation is legally problematic. Much thanks for the patience and time to explain, D.K On Wed, Aug 14, 2019, 17:23 Christian Heimes <rep...@bugs.python.org> wrote: > > Christian Heimes <li...@cheimes.de> added the comment: > > On 14/08/2019 15.37, David K. wrote: > > > > David K. <dikave...@gmail.com> added the comment: > > > > Hi, > > > > 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 > > ssl.match_hostname() > > but on _dnsname_match() which is a method of another inner class. > > My point is that it's still releveant. > > Except it's not revelant any more because that function is no longer > used by CPython's ssl module. Neither match_hostname nor any of its > helper functions are called by code in the ssl module. Since 3.7 all > hostname verification is now performed by OpenSSL code directly. > ssl.match_hostname will be removed in 3.9 or 3.10. > > Latest urllib3 and requests don't use ssl.match_hostname() either. The > urllib3 package has an older copy of the hostname matching algorithm in > urllib3.packages.ssl_match_hostname. It should not be used with modern > Python. > > > 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). > > Your setup has a misconfigured X.509 certificate with a SAN entry that > violates standards for certificates. You are asking me to introduce a > security into Python as a workaround for the misconfiguration. > > The algorithm in match_hostname() and _dnsname_match() implements RFC > 6125, section 6.4.3, in a strict way. Python not only refuses to match > invalid wildcard entries, it also fails hard on RFC 6125 violations. > > > 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. > > You view the fix as simple and harmless. I see it as a violation of > standards and a security bug. X.509 certs are complex and fragile > beasts. Python have had several CVEs in the hostname matching code > because we didn't implement it correctly. Certificates are also used in > legal contracts, e.g. to legally sign documents or establish mutual > trust. You cannot just modify the content of a certificate. > > Since you are worried about the reliability of Python and started > talking about money, have you considered to donate money to the PSF? > Python is maintained by unpaid volunteers. Donations to the Python > Software Foundation help. (Disclaimer: No money in the world will change > my opinion about "dn.strip()".) > > > 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. > > The problem is not the code but the certificate. If you don't care about > valid certificate, then maybe disable hostname / certificate > verification. Or role your own verification. There is no need to modify > any source code for that. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue37845> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37845> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
