2023-05-23
Some views on protocols and encryption
In the context of encryption for NFS, a good question was raised in the comments for this entry:
This makes me wonder, what is it about file-access protocols that they fundamentally "have to" go through a VPN or be tunneled through SSH, in your opinion, instead of using protocol-integrated security like everything else can? (This is in context of workstation-to-server, not server-to-server.)
That is, why we use SSH-over-Internet instead of Telnet-over-VPN, or for example IMAPS-over-Internet instead of IMAP-over-VPN, trusting their built-in encryption and authentication, but reject the same thing in NFS or SMB?
The start of my views is that encrypted NFS with Kerberos is different from IMAPS or encrypted SMTP because both of the latter are instances of '<X> over TLS', while encrypted NFS with Kerberos is its own bespoke, unique cryptographic protocol and implementation. I like '<X> over TLS' (provided that TLS identities are competently handled), because TLS is a well studied, reasonably well understood, and usually well implemented thing (if you use a common implementation, and everyone should). Bespoke cryptography is something I consider dangerous because historically it's had a rather bad track record (both in implementations and in protocols). A lot of effort from many people and hard lessons learned have gone into TLS, far more than into a niche bespoke system (which encrypted NFS with Kerberos definitely is).
(SSH has both historical and practical reasons to not use TLS, and it's often used in environments where non-mesh VPNs would be difficult to substitute for it.)
But that just pushes the question back one level, to why SMTP and IMAP were able to add TLS while NFS or SMB did not (NFS is apparently starting to support NFS over TLS). One part of my answer is 'agility'. SMTP was able to add TLS because it could add a 'STARTTLS' command to the protocol and get people to use it; IMAP was able to add TLS partly because it could also add a 'STARTTLS' command and partly because it was able to add an entire new TCP port that was 'IMAP over TLS'. As a practical matter, NFS has never had this agility; the existing NFS protocols had no easy place to add the equivalent of EHLO and STARTTLS, and the IP ports to use were either fixed or found in arcane ways that made it hard to add a new port for an all-TLS version.
(Here is a mid 2021 FreeBSD article on their NFS over TLS [PDF].)
A somewhat deeper reason is that TLS is not quite a natural match for NFS. TLS provides an encrypted stream, which works fine for IMAP and SMTP because both of those are already stream protocols. However, NFS is in theory a mostly stateless RPC protocol, although today it's transported over TCP streams. This means that a straightforward version of 'NFS over TLS' is encrypting the (TCP) transport stream, not 'NFS' as such. There are similar protocol challenges with DNS over TLS.
(I suspect that the mere existence of this mismatch helps create arguments over the 'right' way to add TLS or encryption in general to NFS and other such protocols, which of course slows down doing it.)
The deepest reason I see is that we never successfully created a generic 'random TCP streams over encryption' system that could be applied to encrypt something without the cooperation of the protocol. People sort of tried in the form of IPsec, but for various reasons IPsec has not caught on and isn't considered desirable today. Without such a system, (mesh) VPN protocols are the de facto solution if you need to encrypt traffic for a protocol that either hasn't been or can't be upgraded to be transported over TLS (or, if you must, some other commonly used encrypted transport protocol).
VPN protocols are sort of like 'encrypt arbitrary TCP streams without the upper layer caring', but they aren't implemented in a way that makes that transparent. With a VPN, you may need a whole connection establishment and monitoring system, and you need to force the upper layer you care about to go over the VPN in some way through tricks as opposed to simply specifying 'this traffic should be encrypted' (a feature that IPsec did support). Tunneling a protocol through SSH port forwarding is narrower than a full scale VPN but still requires fiddling with how the system behaves to redirect its traffic through the tunnel.
(There are programs that you can use to tunnel arbitrary things over TLS in the manner of SSH port forwarding, but they've become less popular over time. One reason for this may be that more and more things have picked up direct support for TLS; another may be that using TLS exposes you to annoying issues with configuring certificate validation and so on.)
As for why file access protocols specifically seem to have been affected by this, one obvious theory is that it's because file access servers and clients are much more likely to be deeply embedded into the kernel and the system as a whole, and seen as very critical. Deeply embedded and critical systems are hard to wrap and resistant to change (you can't just add libssl to them, and TLS in specific has a bunch of complex requirements for things like certificate validation that people don't want to do in the kernel).
PS: If you must use a non-TLS encrypted transport protocol, consider using the WireGuard protocol. There are user level implementations and in general plenty of people are studying its cryptography, so we can probably have reasonable confidence that it's sound. Or there's QUIC, although QUIC is still quite TLS like for obvious reasons, and even the SSH protocol (again, well studied and there are good server and client implementations that you can drop into your system).