Using stronger SSL for communicating

[emdee-is]

You're downloading security files with urllib.request.urlopen which uses the default ssl. create_default_context which defaults to SSLContext(PROTOCOL_TLS) which I think is TLSv1 - not even tlsv1.1 and lets the server choose the cipher (at least in python 3.9).

I think you want to make a ssl.SSLContext with PROTOCOL_TLSv1_2 and also provide a a CAfile in PEM explicitly, to get tlsv1.2 at least. And then even possibly tune the ciphers to get tlsv1.3. Then you give that context to urllib.request.urlopen as a context keyword, along with the cafile keyword.

I expect that PROTOCOL_TLS is susceptible to TLS downgrade attacks - I'm pretty sure I've seen anything less that tls1.3 get downgraded.

[metebalci]

I dont think this is responsibility of the client. The server should not allow TLS <1.3.

[emdee-is]

Please reopen as I think you are fundamentally wrong about SSL in Python.

Before you close it, please test your code against a server that supports tlsv1.3, and verify the cipher after the handshake. Having looked at your code, I'm sure it will not, but I could be wrong, in which case I'll apologize profusely.

I doubt your code (using urllib3) will even check SNI.

Getting a Python client to handshake upto tls1.3 with a 1.3 capable server is not easy in Python from what I'm seeing, and does not work out-of-the-box with urlib3 or requests.

[metebalci]

This is very unrelated to this project. I think what would be useful is to separate downloading and using the downloaded xml, for which I created #15 . So if you have a concern, you can download the xml file with a method you trust and use it locally.

[metebalci]

Just for your information, during TLS handshake, server and client handshakes on a common cipher etc. based on what server offers. If server offers communicating with a less than ideal cipher (even no cipher), independent of client's acceptance to this, this is considered to be problem of the server configuration, hence there is something called correct TLS settings on the server which eliminates using certain ciphers and protocols (even with not good clients). On the other hand, of course client has some flexibility within the ciphers and protocols offered by the server and it should select a good alternative. Like I said that is not point of this project, digsec download is only a quick way to acquire trust anchors (which is just an xml file). It is much better to just offer a way to load this locally so the trust anchor acquisition can become independent of digsec. Just a reminder again, digsec is not a DNSSEC validating resolver (e.g. for production use).

[emdee-is]

There is another part of the process you are not considering: MITM. During the handshake, third parties can get in the way of v1.2 protocol handshakes, but from what I'm seeing, not v1.3. So the few lines of code in your client to get it to fail the SSL connection if it's not v1.3 ensure that the client is getting what it asked for.

What I'm suggesting applies to any Python client using SSL, not even DNSSEC validating resolvers, and it's simply specifying openssl protocol, min_version and acceptable ciphers (usually only a few lines of code).

[metebalci]

Again, digsec is not a DNSSEC validating resolver and the main point of it is not to acquire trust anchors securely and authenticate them. It is also not enough to just download them in the most secure way with SSL. See #15
(side note: MITM cannot be fully prevented by using TLS, hence there is another mechanism to authenticate the trust anchor -see the code mentioned in #15-)

[metebalci]

The official way of doing this will be implemented with #24, and can be done together with using openssl