Repository navigation
FFI interface to SSL_set_min_proto_version etc #5379
Description
OpenSSL 1.1.0 added a number of new functions for controlling the acceptable TLS protocol versions:
int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
int SSL_set_min_proto_version(SSL *ssl, int version);
int SSL_set_max_proto_version(SSL *ssl, int version);
Additionally, OpenSSL 1.1.1 added getters for the same information:
int SSL_CTX_get_min_proto_version(SSL_CTX *ctx);
int SSL_CTX_get_max_proto_version(SSL_CTX *ctx);
int SSL_get_min_proto_version(SSL *ssl);
int SSL_get_max_proto_version(SSL *ssl);
See https://www.openssl.org/docs/man1.1.1/man3/SSL_set_max_proto_version.html for more details of these functions.
The intention, as documented at https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_new.html, is that these functions should be used instead of SSL_CTX_set_options and SSL_set_options for this purpose.
Anyway: it appears that these functions are not exposed via the cryptography.hazmat.bindings.openssl.binding.Binding.lib FFI interface. Could they be added?
Activity
richvdh commentedon Aug 6, 2020
While I'm on the subject, would it also be possible to add support for the
TLS_method(),TLS_server_method()andTLS_client_method()methods which were introduced in OpenSSL 1.1.0:(see https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_new.html)
They are the same as
SSLv23_method(),SSLv23_server_method(), andSSLv23_client_method()respectively, but those three have very confusing names (which is why they were deprecated, I believe).th3b0x commentedon Aug 6, 2020
I would like to second the update of the pyca-cryptography interface to provide the interfaces recommended by @richvdh .
I would like to specifically note that
TLS_method()and related interfaces should be included. In spite of modern OpenSSL versions using a processor macro to mapSSLv23_methodtoTLS_methodit is important to note that the use of the old interface name makes systems vulnerable to malicious library/package replacement. By forcing users to useSSLv23_methodyou are creating avenues of exploitation surrounding malicious insertion of deprecated/obsolete code into system libraries. Since pyca-cryptography merely interfaces with the underlying system OpenSSL library, forcing a programmer to go throughSSLv23_methoddoes not guarantee that they will end up usingTLS_methodeven though the current source code has a macro that makes these methods equivalent.reaperhulk commentedon Aug 6, 2020
Adding these bindings is fine, but there are a few steps:
_conditional.py.The latter is a requirement because maintaining an arbitrarily large set of bindings without knowing consumers turns out to be prohibitively difficult. We've recently stripped numerous methods due to the maintenance burden so we need to have a consumer in our downstream test suite.
th3b0x commentedon Aug 6, 2020
@reaperhulk thanks for the information, I already have some stuff in the works, so I'll look into the issues you've raised.
th3b0x commentedon Aug 19, 2020
@reaperhulk regarding
_conditional.py, given that older versions of OpenSSL would not support TLSv1_3_method, what seems like an appropriate list of dependent functions? I'm tempted to include up to TLSv1_2_method (since TLS_method first appears in major release OpenSSL 1.1.0), but I'm not sure if project guidelines stipulate something more stringent than this. I'm also observing that TLSv1_3 support doesn't seem to always externalized (at least in the last version I pulled; can provide example if required). Any thoughts before I proceed?reaperhulk commentedon Aug 19, 2020
There are two things at play here:
TLS_methodandSSLv23_methodare the same method, so on versions prior toTLS_methodbeing defined we should just define it. That way it's always available.SSL_CTX_set_max_proto_version) bind them with the_HAS_<NAME>pattern we use and remove them in _conditional.py.TLSv1_2_methodis already bound so you shouldn't need to add that. (https://github.com/pyca/cryptography/blob/master/src/_cffi_src/openssl/ssl.py#L349)th3b0x commentedon Aug 19, 2020
@reaperhulk duly noted, thanks for the update. I'm hoping to have something for you guys in the next day or so. This is fairly straightforward since (as noted) SSLv23_method and TLS_method are defined by a macro to be equivalent.
th3b0x commentedon Aug 25, 2020
Edit: looks like it didn't handle correctly on OpenSSL 1.0.2 for some reason, have to check my local environment.
@reaperhulk I've put #5428 in to address the TLS_method related issues. It looks like some of the tests are failing, as you indicated earlier. I'm hoping this tiny PR will help me figure out the odds and ends of doing a PR for this project.
Subsequent to this PR getting through (it's a simple method exposure) I plan on examining what to do about
These functions require a peak at the compiler options, since there isn't a convenient way to handle them for OpenSSL 1.0.2 (will need to do something similar to how SSLv3_method is handled)
mhils commentedon Oct 4, 2020
8bc6920 dropped support for 1.0.2, so implementing this should be more straightforward now. :)
th3b0x commentedon Oct 6, 2020
Got distracted and had to make a new PR, because I borked my branch too much for a clean Rebase.
Current PR in relation to the
TLS_method*interfaces is now #5483I will then be able to proceed to adding the new SSL_CTX option bindings, as requested by @richvdh
Kindly requesting a review at the PR.
Setters and Getters for SSL/CTX Protocols
Setters and Getters for SSL/CTX Protocols
Setters and Getters for SSL/CTX Protocols
Added tls bindings for new OpenSSL APIs
Added tls bindings for new OpenSSL APIs
Added tls bindings for new OpenSSL APIs
Added tls bindings for new OpenSSL APIs
Added tls bindings for new OpenSSL APIs
Added tls bindings for new OpenSSL APIs (#5595)
patches pyca#5379