2021-10-03
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.