OpenSSL TLS 1.1 handshake fails internal error

Status changed to 'Confirmed' because the bug affects multiple users.

I need to verify a few things, but I believe it is to do with chiphersuites, seclevel callback, and protocol versions.

When setting chiphersuite string ; or changing security level; or changing the security level callback; or setting min/mas protocol versions. All of those things are not checked against each other to ensure that as whole they are compatible with each.

Then at connection establishment time things are verified and security callback is called and things go "you request max version y, but security hook rejects things at y, no connection for you".

This does brings the existential/API question similar to the previous bug report. It is not known over the API that security level is 2 and that it rejects protocol versions.

I wonder, if setting min_version / max_version, that would be rejected by the current security level, if security level should be adjusted appropriately automatically. I.e. when trying to set min protocol version to TLS1.1 and the security level is at 2, if security level should be updated to 1 automatically. Or not.

Please note that:

OpenSSL upstream security level 3 only allows TLS v1.1 and above
OpenSSL upstream security level 4 only allows TLS v1.2 and above, DTLS v1.2 and above

On Ubuntu, these restrictions are brought in earlier at security level 2.

Thus, if one builds upstream OpenSSL with security level set to 4 all of the above testsuite should be failing as well.

I feel there is lack of API documentation about this in OpenSSL.

Also, Python tests are incomplete and are not testing for, or setting appropriate security levels for the protocols they are attempting to use. Thus are not using the OpenSSL api correctly and making assumptions about the openssl library that are out of date with current standards and requirements.

I didn't include a setter for security level on purpose, https://bugs.python.org/issue41195 . Most recent Python version only has a getter to query security level. I strongly believe that user application should not modify security level. Security level and TLS versions should be centrally managed by system administrators. Unfortunately Python's ssl module still has legacy support for TLS 1.0 and 1.1.

Even a check for seclevel == 2 or modification of the security level wouldn't address Python's test failures on Ubuntu. After all Ubuntu uses a custom policy that deviates from the seclevel 2 definition
at https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_get_security_level.html

Do you suggest that Python should check for Ubuntu in the test suite, so we can special case Ubuntu's custom policy?

I feel that openssl upstream needs to add:

server_context.verify_consistent()

Because in the above example, even before trying to establish the connection between the two context, the server context is already internally inconsistent.

And upstream has changed the meaning of security levels in the past, and will do so again in the future. Ditto distro customization which brought the preview of such change earlier.

It does feel that until such API arrives upstream, one needs to do something to the effect of:

1) if openssl version 3.x, and security level is greater than 0, assume no TLS1.1 is available
2) if openssl version 1.1.1+, and security level is greater than 1, assume no TLS1.1 is available
3) if ctx.get_min_proto_level returns TLS1.2 assume no TLS1.1 is available
4) else try setting min_proto_level and run tests
5) if min_proto_lvel is not available the build is against openssl 1.0.2x series, TLS1.1 is probably available.

Above logic should cover the next upstream openssl version; the current deployments of ubuntu derivatives; the debian derivatives; and fedora/rhel derivatives.

I think....

ideally it would be nice if we could access sec_cb and call it with the protocol versions to check the versions there.

Oooh,

can we add bindings for:

s->cert->sec_cb() and then call it with SSL_SECOP_VERSION operation with nbits set to TLS1.1 version? then it will return and tell us if it is acceptable or not, by the security level.

> I feel that openssl upstream needs to add: server_context.verify_consistent()

Yeah, I agree with you. :) The idea came up three years ago when I filed issue https://github.com/openssl/openssl/issues/5127

> 1) if openssl version 3.x, and security level is greater than 0, assume no TLS1.1 is available

Thank you, I'll consider this fact when I implement OpenSSL 3.0.0 support

> 2) if openssl version 1.1.1+, and security level is greater than 1, assume no TLS1.1 is available

TLS 1.1 connections work fine on seclevel 2 with default upstream OpenSSL 1.1.1 and with Fedora's OpenSSL 1.1.1 using crypto-policy "DEFAULT". I'm using

    server_context.set_ciphers("@SECLEVEL=2:ALL")

to change the security level. Here Ubuntu deviates from standard OpenSSL 1.1.1 policies. So I ask again: Should we detect and special case the deviation and document it?

> 3) if ctx.get_min_proto_level returns TLS1.2 assume no TLS1.1 is available

That's the original problem, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878 . On Ubuntu SSL_CTX_get_min_proto_version() returns 0 (lowest available version) and TLS1_VERSION is available.

> 4) else try setting min_proto_level and run tests

The setter SSL_CTX_set_min_proto_version() does not return an error indication.

> s->cert->sec_cb() and then call it with SSL_SECOP_VERSION operation with nbits set to TLS1.1 version? then it will return and tell us if it is acceptable or not, by the security level.

Nice!
Could you hook up the check to SSL_CTX_set_min_proto_version() and return an error code when level and security policy don't match? It's a modern setter, so it can return 0 on error.

    int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);

> Could you hook up the check to SSL_CTX_set_min_proto_version() and return an error code when level and security policy don't match? It's a modern setter, so it can return 0 on error.

That is interesting proposal.

However, need to be careful as to potentially not break configs, i.e. if they specify min_protocol_level first, then lower the security level.

> to change the security level. Here Ubuntu deviates from standard OpenSSL 1.1.1 policies. So I ask again: Should we detect and special case the deviation and document it?

I am reluctant to say yes here. But also want to ask how would you detect that it's an Ubuntu, or ubuntu derived openssl. I don't think we export anything in openssl APIs to be definitive about it.

Opened https://github.com/openssl/openssl/issues/14607

Hi Christian, I'd like to move forward with this ticket and I think that will mean closing it. But first, have things changed on your side?

Also, like Dimitri I am reluctant to commit there but I don't see things changing until the next openssl LTS release as I've said in https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/comments/21 . I haven't spotted an easy way to detect the system is Ubuntu (and which version) but maybe you can do that at python configure-time if it's needed.