I can get copyparty to work nicely in some circumstances - like on the LAN. The disk space is much more cheap and abundant on a self-hosted server, as opposed to on a rented VPS in the cloud. But then sooner or later, one wants to access it remotely (not just within one’s home LAN).

So then one gets the idea to set up some sort of reverse proxy on a cloud server, leading to the server within the LAN. There’s more than one way to do this, and each possible approach has its tradeoffs. What all these varying approaches have in common, is that they’re all much harder to set up, going beyond the original intended scenario that the original developers had in mind (which doesn’t take into account complicating factors like frustratingly expensive hard drives, firewalls, NAT, etc).

In the case of securely sharing files over the WAN, I wanted a method which hides traffic from the hypervisor on the VPS - so the hosting company (renting out the VPS) can’t use their hosting priveleges to see the traffic, in a Man-In-The-Middle (MitM) sort of way.

Let’s first take the case of Copyparty, my favorite way to share files over a network. Copyparty is accessible from any old web browser as a client. This universality is very appealing. Contrast this to the varying support for other file-sharing methods I also know well: SMB, Magic Wormhole, rsync, etc.) Notably, Syncthing is delightfully universal also, but is too complex for most users to understand. It’s effectively “geeks-only”.

With Copyparty, I can secure the traffic using SSL on both the backend Raspberry Pi (where I run it), and the VPS (where a reverse proxy runs, leading to the Raspberry Pi on the backend). But alas, the hypervisor on the VPS gets to see the private key for the SSL. The hosting company can trivially help themselves to the juicy privkey.pem files, which are likely to be stored in /etc/letsencrypt/live/*/

OK, what about using Copyparty’s builtin FTP server? What’s nice about FTP clients like Filezilla, is that they aren’t as fussy and access-impeding as most modern web browsers, should one wish to use a self-signed SSL certificate.

Note: I’ll refer to FTP-with-SSL as “FTPS”, for short, so as to not confuse it with SFTP, the file-sharing subsystem of the SSH server.

I tried out using haproxy’s “tcp mode” (to reverse-proxy SFTP connections into my LAN, where Copyparty’s FTP server was listening, using its own self-signed SSL cert). This avoids LetsEncrypt, and avoids exposing that privkey.pem on the VPS. But alas, FTPS hates being behind such a reverse proxy. The source IP address will look inconsistent - is it the client’s IP address, or the proxy’s IP address, after successful login? So FTPS throws up its hands at this inconsistency.

If only there were some secure alternative, where this varying source IP address wasn’t an issue, when reverse-proxied in this way (by haproxy’s “tcp mode”). It turns out, lucky attempt number 3, SFTP doesn’t have this limitation. SFTP is the SSH server’s really-great quality file-sharing feature. Haproxy can similarly reverse-proxy the SFTP traffic in “tcp mode”, on the VPS; thereby also dodging the privkey.pem being stored on the VPS.

I used haproxy and a Wireguard tunnel on the VPS, as opposed to opening ports (for port forwarding) in any ISP or home routers. Why? because the ISP can upgrade or change the firmware settings in their routers at any time, which can and will erase these port-forwarding settings without warning. It might work for months, but then one day it just stops working. Murphy’s law is that it’s when you’re out of town, or in another country!

Final note: it would be wise to pay careful attention to the “fingerprint” on that first SFTP connection, to be extra careful that no MitM is happening.