Do Python 3.6 and Requests Module conform to RFC 6125 for wildcard reference identifiers?

Question

I am trying to ascertain whether Python's request module conforms to RFC 6125 or not.

I created a Root CA Certificate and added it to my Linux's Trust Store. I then created a Server certificate and signed it with my Root CA Certificate and put the common name as "*.com". Then I started a server using OpenSSL's s_server using the Server Certificate.

Now as per RFC 6125 and this question, my python client should not establish a TLS connection if i try to connect with "foo.com". However, the Python client does not fail here and establishes a connection. I am executing this command in the terminal:

python -c "import requests; print(requests.get('https://foo.com', verify='/etc/ssl/certs/ca-certificates.crt'));"

But, if i try to connect with "bar.foo.com", i get the expected error:

requests.exceptions.SSLError: HTTPSConnectionPool(host='bar.foo.com', port=443): Max retries exceeded with url: / (Caused by SSLError(CertificateError("hostname 'bar.foo.com' doesn't match '*.com'",),))

In my opinion, this is a very trivial thing that should not happen.

So is there something wrong in my approach or does the Requests Module actually not fail in this scenario?

Looking forward to your help guys!

Thanks!

Answer 1

The problem was already reported in issue 29824. But, it was considered as 'wont fix':

Matching wildcard in public suffix
...
Yes, it would be beneficial to have more elaborate checks to protect against wildcard attacks like *.com. However Python is not a browser. It's really hard to do it right and even harder to keep the rule set up to date. Some TLDs like .uk have sublevel namespaces, e.g. co.uk. *.co.uk is also invalid.

Apart from that newer versions of Python simply use the functionality of OpenSSL to check the hostname:

The problem is going to shift anyway. For Python 3.7 I'm going to deprecate support for OpenSSL < 1.0.2 and use OpenSSL's hostname verification code instead of ssl.match_hostname().

Only, that OpenSSL does not care about public suffix either.

I personally don't bye the argument that this is too hard too do in the first place and it is hard to keep up-to-date. There is a publicly managed list of such public suffixes at publicsuffix.org and the syntax is not hard to parse so that one can also find several implementations in Python for dealing with the list.