187 karma · joined December 19, 2021
I have no mechanism at the moment for revoking host keys, which is a harder problem to solve as it would involve updating a number of laptops, phones, etc. that may not be powered on at a given time, but that’s less of a problem since if I knew a host key had been compromised I wouldn’t be logging into it anyway.
Yep.
> There are some other machines that you want to SSH into. They trust CA public key.
Yep, with TrustedUserCAKeys.
> The remote servers trust the certificate issuer, verify that you own the certificate’s private key, and let you in.
Yep. Additionally, the servers themselves present CA‐signed certificates alongside their host keys. My GlobalKnownHostsFile contains the CA public key, so when I connect to a host for the first time, there’s no “unknown host” warning and my user’s known_hosts file is not updated.
> If so, how do you issue the certificates that live on RPi?
The CA has a directory containing the public keys of every user and host that I set up. A cronjob periodically runs ssh-keygen -s against these files, and copies them to htdocs. Each host and user has a cronjob that periodically fetches its certificate and copies it to /etc/ssh or ~/.ssh, respectively.
It’s more convenient for me than updating authorized_keys. When I build a new machine, for example, I first generate a new SSH keypair on the machine. Then I copy the server and user public keys to the CA. Once I drop them in the right folder, certificates get generated automatically and served over HTTP. Then on the new machine I set up cronjobs to refresh the certificates every two weeks. I didn’t have to update authorized_keys on a dozen other machines, and I didn’t have to inspect any host fingerprints.
> If a host has been accessed by an attacker due to an exfiltrated key in the past it's tainted forever.
Yes, that’s obvious (although I did mention shell script in my previous comment—been a while since I thought this through). The scenario I imagined at the time was more like, did I ever copy my private key to an unencrypted flash drive, and then lose the flash drive? I never let private keys leave a machine anymore, but maybe I wasn’t so strict about that five years ago, and when did I generate my main SSH keypair? Was it four, five, six years ago? I no longer have to worry about such things. I could have just rotated my keys, but with short‐lived certificates I now get the benefits of key rotation without having to do any of the work.
Now I tie all my SSH keys to a WebAuthn key, which provides even more protection, because within the three‐week window that my certificates are valid, an attacker would have to also physically possess my Yubikey.
> But I've been burned before when a central auth server was down and I couldn't log into my servers
There is no central auth server involved here. My servers check login credentials against the CA’s public key, which is installed alongside my sshd config file. I make my certificates valid for three weeks, but regenerate them every two, so if some failure happens with creating or fetching certificates I have a week to notice and fix the problem.
No, the only files served to the LAN are the certificates, which contain the signatures by the CA of the public keys of other machines. Those are safe to distribute openly because they’re useless without the private key of the public key that was signed.
In another comment I went into more detail about how I keep the CA secure.
Compared to my desktop, where over the years I ran all kinds of stuff from the package manager, downloaded Python scripts and configure scripts from GitHub and Sourceforge… I tried to be careful but you can’t audit everything.
The main benefit I get from using SSH certs at home is expiration. Before, I always had a niggling feeling at the back of my mind that the public key I’d been using for four years could have been surreptitiously exfiltrated by some shell script three years ago, and I’d never notice.
Now my certificates expire regularly, so I no longer have to worry about whether my machine remained secure throughout the entire continuous past; I only have to worry if my machine is secure in the present.
I don’t think I had any problems like that with the writing of other fantasy series like Lord of the Rings and A Game of Thrones. Nor with two other trilogies I read for the first time this year, C. S. Lewis’s Space Trilogy and The Three‐Body Problem.
If you have disk space to spare, I would recommend downloading GOG’s offline installers as a backup. The risk of the service disappearing or games you’ve bought being removed seems pretty low, but DRM‐free offline installers are just as good as the classic “physical copy,” provided you actually saved them!
Sure, I’m nowhere near a bank director on the list of “attractive targets for voice cloning,” but who knows how widespread this attack might become in the future, and by the time one’s voice is out there on the Net, there’s no way to take it back.
I would like to use a voice changer when making phone calls to businesses too. I can totally imagine future corporations creating a new revenue stream by selling models of a known person’s voice to advertisers so they can later correlate the voice to that person.
Unfortunate that Lyrebird’s transformations seem easy to reverse. I wonder if there are any FOSS tools that make it harder to recover the original voice.
Yes, that and RDNS.
> If you're paying for that, why not just pay for a static IP at home?
That’s a good question. I too hear that mail providers consider IP blocks assigned to VPS providers less trustworthy than others. The reasons I don’t take the ISP/dedicated server route, aside from price, are:
• VPS providers are not tied to my physical location. If I move, I probably can’t take my ISP’s static IP with me (I may even move to somewhere they don’t service). Conversely, if I want to switch away from a local ISP, the selection of alternatives is extremely limited.
• Risk of neighboring IPs reducing the reputation of the block exists with server companies and local ISPs as well. I concede that the problem is probably worse with VPSes, but I hope to mitigate it somewhat by avoiding bottom‐of‐the‐barrel providers and by the fact that my own IP will never be used to spam.
• I’m somewhat worried about the possibility of DDOS, and VPS companies provide a lot of cheap bandwidth, so in case of attack I might be able to salvage the situation with careful firewalling on the VPS.
I agree that hosting a mail server directly on a VPS compromises privacy and control. But there’s a better alternative: use VPSes for cheap static IPs, while hosting the server locally on hardware you physically control, using WireGuard tunnels and port forwarding to connect things. Port forward incoming SMTP over WireGuard to your real MX, and use MTA‐STS and DANE so that as many senders as possible will TLS‐encrypt mail they send you. Have your outgoing SMTP server handle DKIM signing, then send it out via WireGuard so it looks like it came from the VPS, while enforcing TLS encryption.
The VPS won’t be able to forge mail from you without your DKIM keys. It won’t be able to read your outgoing mail due to TLS. It won’t be able to read incoming mail that’s TLS encrypted. It will be able to read unencrypted mail, but the big providers that follow MTA‐STS will abort if the VPS attempts to block encrypted connections.
This has the added benefit of reducing your dependence on an external provider (the VPS company) for server setup. If you’re unhappy with a particular provider, just switch to another one. The issues associated with sending email from a brand new IP will be there, but you won’t have to set up complicated infrastructure on the new host, only a few WireGuard tunnels and firewall rules.
Obviously GMail is such a giant that email providers have to be very careful when blocking it, but enough spam comes from there that receivers clearly use some heuristics to block some of it. I’ve even received multiple rejection notices because the GMail server my email was sent through happened to be on a blacklist!
I switched last year to sending directly from my VPS. It was partly for privacy from Google, but moreso so I could enforce outgoing TLS. For the first few days they went to spam boxes or moderation queues, but I made sure they were rescued, and ever since I’ve had no deliverability issues sending to Google, some local ISPs, and even Microsoft (which seems crazy, as I never got a mail from my domain to show up in Outlook when I was relaying through Google).
I can only speak for my own experience, of course. But that is what I experienced.
For several years I’ve hosted in the “middle ground” sense described by the OP, running my own incoming mail server and relaying outgoing mail through a big provider.
The main benefit for me (compared to using a big provider with my own domain) is personal privacy. When I used Google for mail, Google had access to so many pieces that make up my personal life: Purchase receipts. Flight itineraries. Conference registrations. Emails from my university. Emails from my realtor. Utility bills. Notifications for subscribed forum threads, GitHub repositories, Wikipedia pages. Whatever newsletters I chose to subscribe to. Theoretical access to any site with password reset by email. Running my own MX eliminates Google’s access to most of these things.
There are other some other benefits too. Free infinite aliases I can use to sign up on any website. No fear of dependence on features that might get paywalled. No sudden danger of having to migrate data to another provider.
> If you're spending more than an hour a year maintaining your self hosted email (which you will, big time!) then your Google Workspace / O365 is paid for.
Reducing my data footprint is something I care about enough to spend my spare time on.
So far the most spam I’ve gotten has been to the address I used for Amazon (probably leaked by a third‐party seller there).
Well, there are other reasons to prefer using external hosting. Home connections are typically port‐filtered, have dynamic IP addresses, and have a low IP reputation, and your ISP selection is very limited. Whereas if using a VPS there are so many options that it’s easy to shop around.
But you can still self‐host while getting the benefits of a VPS. Just forward ports from the VPS over a WireGuard tunnel to your real machine. Then all the actual infrastructure is on hardware you control, and the cloud provider has no access to your TLS private keys.
> The longer-term solution is to wait for DoT to become prevalent in authorative servers.
That has a serious deployment problem, far more so than ECH. It’s going to be years (and years and years) before a person can successfully do recursive resolution via TLS. Is that even on anyone’s roadmap?
I use cloudflared to do DNS lookups via Cloudflare’s Tor onion. It’s weak to vulnerabilities like this one, but it disassociates my DNS lookups from myself, and TLS certificates mitigate the risk of hitting spoofed sites.
I’m no stranger to self‐hosting, and I personally run my own email server (with MTA‐STS, DANE, and mandatory TLS for outgoing mail) and Mumble for voice chat, and even Pleroma. These have all been very reliable, enough that I regularly communicate with friends this way. In contrast, my Matrix experience makes me reluctant to suggest it to anyone I know, because it’s hard enough to get anyone onto something user‐friendly like Signal.
I want to love Matrix. The idea is really cool, there is obviously a lot of work behind it, and I appreciate having something federated to compete with Signal’s model. But it just hasn’t worked for me. I hope the self‐hosted situation will improve.
I know of three sources: VHX, Vimeo On Demand, and GOG. Although upon looking it appears VHX is now owned by Vimeo, so there are really only two.
One thing I’m not sure of is what happens if I want to switch registrars in that time—will the full 10 years of ownership transfer to the new registrar?