Encrypting Files and Connections
Three small experiments on a couple of VMs, each about a different place data can be protected: at rest on disk, in transit between two programs, and underneath a protocol that was never designed to be encrypted at all. None of them is exotic, and that is the point, these are the standard tools, used by hand until they made sense.
Encrypting a directory with eCryptfs
eCryptfs is a stacked filesystem: you mount it on top of an ordinary directory, and everything written through the mount is transparently encrypted on the underlying disk. I mounted a directory with a passphrase, created a file with some plaintext in it, and then unmounted.
The test that makes it real is reading the raw file with the mount gone. With eCryptfs unmounted, the file on disk is ciphertext, the filename and the contents are both unreadable. Remounting with the same passphrase and printing the file gives the plaintext straight back. The plaintext only ever exists while the mount is live; on disk there is nothing but encrypted bytes.
A private CA and mutual TLS with OpenSSL
The second piece was building a small public-key setup from scratch with the OpenSSL command-line toolkit: my own certificate authority, then server and client certificates signed by it. The CA is just a key pair and a self-signed root; once it exists, it can sign anything.
With the certificates in place, openssl s_server and
openssl s_client are enough to stand up a TLS endpoint and connect to it.
The interesting mode is mutual authentication: the server is told to require a client
certificate, so each side has to present a certificate the other can trace back to the
CA. The debug output shows the chain being verified in both directions, which is the
whole idea of mutual TLS, neither end trusts the other until the certificate checks
out. Running it with the web option even lets a browser connect and present a client
certificate, the same client-certificate authentication that real services use to gate
access.
Wrapping NFS in a TLS tunnel
NFSv4 sends its traffic in the clear by default, which is fine on a trusted LAN and
alarming anywhere else. Rather than reach for a different protocol, you can tunnel it.
I set up an NFS server exporting a directory, then put stunnel in front of
it on both ends to create a TLS tunnel between client and server, the server side
holding a self-signed certificate whose root is copied to the client.
The trick is where each side points: the NFS server exports to the local end of the tunnel rather than directly to the client, and the client mounts from its own end of the tunnel. The NFS traffic now flows through TLS without NFS knowing anything about it. Capturing the link before and after tells the story, the same mount that showed readable NFS packets shows only encrypted bytes once the tunnel is up.
The common thread
Encryption at rest, mutual authentication in transit, and a TLS wrapper around a cleartext protocol are three answers to the same question of who can read your data and who you can trust. Doing each one manually, and then capturing or dumping the raw bytes to confirm it worked, is what turned them from settings I enable into mechanisms I understand.