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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1917625 Title: OpenSSL TLS 1.1 handshake fails internal error Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Hirsute: Confirmed Bug description: OpenSSL's SSL_do_handshake() method fails with TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled but server side has only TLS 1.0 and 1.1 enabled. The issue breaks Python's test suite for test_ssl. It looks like the problem is caused by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are not affected. A simple reproducer is: import ssl import socket from test.test_ssl import testing_context, ThreadedEchoServer, HOST client_context, server_context, hostname = testing_context() # client 1.0 to 1.2, server 1.0 to 1.1 client_context.minimum_version = ssl.TLSVersion.TLSv1 client_context.maximum_version = ssl.TLSVersion.TLSv1_2 server_context.minimum_version = ssl.TLSVersion.TLSv1 server_context.maximum_version = ssl.TLSVersion.TLSv1_1 with ThreadedEchoServer(context=server_context) as server: with client_context.wrap_socket(socket.socket(), server_hostname=hostname) as s: s.connect((HOST, server.port)) assert s.version() == 'TLSv1.1' On Ubuntu 20.04 the code fails with: Traceback (most recent call last): File "/internalerror.py", line 15, in <module> s.connect((HOST, server.port)) File "/usr/lib/python3.8/ssl.py", line 1342, in connect self._real_connect(addr, False) File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect self.do_handshake() File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:1123) On Debian testing and Fedora 33 the same test passes with out: server: new connection from ('127.0.0.1', 52346) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256) server: selected protocol is now None You can find Dockerfiles with reproducers at https://github.com/tiran /distro-truststore/tree/main/tests/ubuntu-1899878 Also see: * https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878 * https://bugs.python.org/issue43382 * https://bugs.python.org/issue41561 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
