Using stronger SSL for communicating about digsec HOT 7 CLOSED

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

from digsec.

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.

from digsec.

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.

from digsec.

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

from digsec.

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

from digsec.

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

from digsec.

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

from digsec.