On 2019-10-27 23:13, Daniele Tricoli wrote:
On Sun, Oct 13, 2019 at 10:31:31PM +0800, Drew Parsons wrote:
It conditionally works. Using curl, I found that TLSv1_0 or TLSv1_1 will support a successful connection, but only if the maximum SSL_VERSION is constrained to TLSv1_0 or TLSv1_1 (e.g. curl -v --tlsv1.1 --tls-max 1.1
https://pub.orcid.org). Without the max, the connection fails:
$ curl --tlsv1.1  https://pub.orcid.org
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake

The urllib3 failure was similar, but I do not know how to set tls-max with urllib3. I could only find the option with curl. I could set up a custom HTTPAdapter as suggested at https://requests.readthedocs.io/en/master/user/advanced/#example-specific-ssl-version to set ssl_version=ssl.PROTOCOL_TLSv1_1 but the ssl module doesn't have the SSLVERSION_MAX_TLSv1_1 value that curl has. I could solve it with pycurl
using c.setopt(pycurl.SSLVERSION, pycurl.SSLVERSION_TLSv1_1 |

For sure I'm missing something, but why not just set TLS version?
I tried the following on both Python2 and Python3:

    >>> import ssl
    >>> from urllib3.poolmanager import PoolManager
    >>> http = PoolManager(ssl_version=ssl.PROTOCOL_TLSv1)
    >>> r = http.request('GET', 'https://pub.orcid.org')
    >>> r.status

That's a good tip, I missed that permutation. I was originally trying to access using the requests module, so didn't think to do it directly with urllib.PoolManager

Evidently the orcid server only supports TLSv1.0 and TLSv1.1 and no higher (why haven't they activated TLSv1.3 yet?!), while curl and urllib3 without tls-max first test TLSv1.3 and then quit without cascading downwards once they receive the TLSv1.3 handshake failure. Which is rather odd behaviour when I think about it. The whole point of supporting multiple protocol versions is to try the next available version if the first one doesn't work.

Not an expert here, but I think fallback is not done on purpose due downgrade
attacks: https://en.wikipedia.org/wiki/Downgrade_attack

I see. Still an odd kind of protection though. The attacker can just downgrade themselves.

I had a closer look. The failing tests were in python2 only, coming from
the non-ascii (Gërman http://Königsgäßchen.de/straße and Japanese
http://ヒ:キ@ヒ.abc.ニ/ヒ?キ#ワ) unicode url tests.
Fixed adding python{,3}-idna on B-D. I had to add python3-idna
because the same tests were failing also on Python3 when I tested
them buinding on DoM.

Thanks for that, and thanks again for the PoolManager tip.


Reply via email to