Mysterious SSL/TLS network connection failures in Debian Buster+
Changes to default TLS to ≥ 1.2 breaks weird stuff
Necessary Background
One of the more fundamental aspects of modern networked computers is the overlay of Transport Layer Security (TLS, and the successor to SSL) on TCP or UDP connections to provide identity and encryption guarantees. These protocols sit underneath higher level protocols such as HTTP, HTTP/2, gRPC, QUIC, MySQL, Redis and so fourth transparently encrypting and decrypting information on either side of the connection.
The protocol has gone through several revisions; from SSL being phased out in favour of the newer TLS, and TLS itself going through versions 1.0 → 1.3. These revisions each address weaknesses in the former design of the protocol that can allow leaking of the content of that encrypted connection, or even the theft of the unique cryptographic keys that underlie the connections security.
The most recent version is the recently released TLS 1.3, with TLS 1.2 and TLS 1.1 largely deprecated at this point.
Changes in OpenSSL Packaging
One of the cryptographic libraries that is commonly used to handle the mechanisms of this connection is OpenSSL, and is packaged in Debian. Debian takes care of maintaining secure defaults in this package, mitigating the risk for both servers where Debian is run, as well as the few of us who run Debian on the desktop.
The default that was “recently” changed to support TLS 1.2:
openssl (1.1.1~~pre3-1) experimental; urgency=medium
* Update to 1.1.1-pre3
* Don't suggest 1024 bit RSA key to be typical (Closes: #878303).
* Don't insist on TLS1.3 cipher for <TLS1.3 connections (Closes: #891570).
* Enable system default config to enforce TLS1.2 as a minimum.
-- Sebastian Andrzej Siewior <__AUTHOR_EMAIL__> Wed, 21 Mar 2018 00:01:08 +0100While applications can override this default by explicitly allowing it in the OpenSSL library, by default the library will refuse to negotiate connections with TLS < 1.2.
Oh god, things are broken
It turns out, a surprising amount of things aren’t packaged with support for TLS 1.2. Though that protocol is now 10 years old, various bits of software and hardware still appear not to be able to “speak it”. This manifests in rather opaque connection failures, such as VSCode indicating that one is not connected to the internet, or WiFi prompting for a user password though the user password is still correct.
The errors for WiFi turn up under wpa_supplicant, but the errors for VSCode were tracked down by GitHub user cwebster2:
---> Interop+Crypto+OpenSslCryptographicException: error:0E076071:configuration file routines:MODULE_RUN:unknown module nameThis opaque looking reference is because the dotnet libraries are not fully interoperable with the new configuration changes Debian has made.
It’s likely other stuff will also mysteriously fail to connect. Each connection error will look different, and if the application logs well that should be fine — however, in my experience the errors are opaque and difficult to handle.
Temporary resolutions
The simplest solution is to revert the default for TLS 1.2 in the system configuration:
[default_conf]
# The below line is the one that requires TLS 1.2. Commenting
# it out makes things work again
#
# ssl_conf = ssl_sect[ssl_sect]
system_default = system_default_sect[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
This is perhaps not an ideal solution. However, it does allow connection to the wifi network, which is what I need to keep working.
In Conclusion
TLS is one of the more foundational things on which all of our networks are built upon. It is something that will invariably require debugging at some point, though perhaps the above will help save you some time investigating this further yourself.
Computers are fun.
