Python 3.6和Requests Module是否符合RFC 6125的通配符引用標識符?

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


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

我試圖確定Python的請求模塊是否符合RFC 6125。

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.

我創建了一個根CA證書並將其添加到我的Linux的Trust Store中。然后,我創建了一個服務器證書,並使用我的根CA證書對其進行了簽名,並將公用名稱設置為“* .com”。然后我使用服務器證書使用OpenSSL的s_server啟動了一個服務器。

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:

現在根據RFC 6125和這個問題,如果我嘗試連接“foo.com”,我的python客戶端不應該建立TLS連接。但是,Python客戶端不會在此處失敗並建立連接。我在終端中執行此命令:

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:

但是,如果我嘗試連接“bar.foo.com”,我會得到預期的錯誤:

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'",),))

requests.exceptions.SSLError:HTTPSConnectionPool(host ='bar.foo.com',port = 443):使用url超出最大重試次數:/(由SSLError引起(CertificateError(“hostname'sbar.foo.com”不匹配) '* .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!

1 个解决方案

#1


3  

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

問題已在問題29824中報告。但是,它被認為是“不會修復”:

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.

在公共后綴中匹配通配符...是的,進行更精細的檢查以防止像* .com這樣的通配符攻擊將是有益的。但是Python不是瀏覽器。要做到這一點真的很難,甚至更難保持規則設置。像.uk這樣的一些TLD具有子級命名空間,例如co.uk. * .co.uk也無效。

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

除了較新版本的Python之外,只需使用OpenSSL的功能來檢查主機名:

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().

無論如何,問題仍將轉移。對於Python 3.7,我將棄用對OpenSSL <1.0.2的支持,並使用OpenSSL的主機名驗證代碼而不是ssl.match_hostname()。

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

只是,OpenSSL也不關心公共后綴。

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.

我個人並不認為這一點太難了,而且很難保持最新狀態。 publicsuffix.org上有一個公開管理的公共后綴列表,並且語法不難解析,因此人們也可以在Python中找到幾個用於處理列表的實現。

关注微信公众号

注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2018/02/27/7dee7e63844a2cd9e0d9ea4e811378e5.html



 
粤ICP备14056181号  © 2014-2020 ITdaan.com