Wandering Thoughts archives

Modern TLS has no place left for old things, especially clients

The TLS news of the recent time interval is the expiration of Let's Encrypt's R3 intermediate certificate and then the DST Root CA X3 certificate (for background, see Let's Encrypt's blog entry or Scott Helme). There were a variety of issues that came up (ZDNet, Scott Helme), but one common thread across many of them is that they involved old things. Old operating systems (such as old versions of macOS), old code, old middleware interceptor boxes, and so on. Although the specific details are always surprising, the general trend should not be, because it's been clear for some time that modern TLS is unfriendly to old things.

(Before this it's been the turn of old, historical browsers and old web servers.)

The modern TLS world is full of changes. Old root certificates are expiring and new ones are being introduced to replace them. Old code for certificate validation was never exposed to multiple chains, some with now invalid certificates, and either doesn't implement handling for it or has bugs in that code. Old TLS ciphers and versions are being deprecated and new ones introduced, as the TLS world moves to TLS 1.3 now and some version in the future. Not only does nothing stand still, with new things being added, but the old things don't keep working; they break or get turned off.

Some of this will be better in the future. For example, since it's happened already and will again, actively maintained TLS client code will increasingly deal properly with multiple certificate chains where some of them are expired or otherwise invalid. TLS 1.3 has some mechanisms to force client and server code to better cope with strange new things (such as seeing TLS extensions offered that you don't know about), and so we can expect fewer explosions in the future in clients, servers, and middleware systems. But other things can't be made correct now and then left alone for years. The set of root certificates you need is going to change, and someday there will be a TLS 1.4 that will become required. Nothing will help old things then.

(And probably we will discover new bugs and issues in old TLS code when other changes happen in the future, since we always have so far.)

Regardless of what one things about this situation with modern TLS, it exists (as demonstrated recently in the Let's Encrypt related issues). TLS things that are old today are going to be less and less functional over time; TLS things that are current now but stop being updated will also be less functional over time, but it will take longer for it to really happen. And there's no real prospect of this changing any time soon.

(Some of this is ideological on the part of the people involved in TLS development. They feel strongly that TLS was frozen for too long, to the detriment of its security, and that this should not be allowed to happen in the future.)

Desktops don't always use NetworkManager's programs

Three things are definitely true on modern Linux and modern Linux desktops. Pretty much everyone is using NetworkManager, NetworkManager includes GUI frontends, and desktops have GUI interfaces for controlling your active networks and configuring them. In a nice regular universe, the desktop's GUI frontends would be using the NetworkManager GUI frontends like nm-applet and nm-connection-editor, and would thus usually automatically support everything that NetworkManager itself supports (since the NetworkManager developers tend to update their GUI frontends when they add features like support for WireGuard or for "metered" connections).

Unfortunately this isn't a nice regular universe, so several major desktops do not use the NetworkManager programs for their GUI and as a result can be missing support for NetworkManager features. GNOME and Cinnamon definitely use their own code for both controlling active network connections (what nm-applet is used for) and for configuring network connections (what nm-connection-editor is used for). Cinnamon's version doesn't support WireGuard VPNs or setting connections to "metered" status, as I've found out over time; I don't know about the state of GNOME's. I believe that KDE has its own applet; I don't know if it uses the NetworkManager connection editor.

(The GNOME and Cinnamon desktop shells both implement applets as Javascript code that runs in the context of the desktop shell, instead of as separate programs. However, Cinnamon can use nm-applet instead of its own thing if you do the right magic things. I don't know about GNOME.)

Generally you can run nm-connection-editor directly if you want to (and remember what it's called); it appears to work when run directly even in a GNOME Wayland session. Some desktop environments (such as Cinnamon) may offer you a confusingly named additional "applet" menu option that runs nm-connection-editor instead of the desktop's own connection editor (on my Cinnamon desktop it's called "Network Connections", instead of the "Network Settings" that invokes Cinnamon's own, limited version). Unfortunately as far as I know there may be no way to run nm-applet instead of your desktop's less up to date version, and even if you can you may lose other features in the overall desktop environment.

You might reasonably ask why this matters. One of the reasons it's mattered for me in the past is that it can be rather confusing to read some online documentation and then not find what it's talking about in my Cinnamon desktop environment, because the online writing is talking about the official NetworkManager way (and may be written by someone on a desktop environment that does use the NM programs). It also complicates having full support for things like metered connections and WireGuard links, because it's not enough for them to be present in the official NetworkManager programs; they also have to make their way into all of the desktop reimplementations.

PS: The situation with nm-applet can be especially confusing in Cinnamon (at least); my desktop session actually has a nm-applet process running, despite not using it. A test GNOME session doesn't behave this way. Since my Cinnamon desktop environment has been around for a while (it looks like since 2013, since even my laptop environment has been long-lived), starting nm-applet may be inherited from old days when Cinnamon actually used it.