Hi Anders! I just wanted to say I saw your project and it looks like it’s going to be great to help people have a self hosted server without going through a bunch of technical setup, the project looks awesome! I just wanted to comment/feedback that probably from a users’ perspective with this kind of software one of the main concerns would be how could the user know that their connection was end to end encrypted all the way to localhost (and not decrypted at all in between) and that their basic auth username/password combo is not shared with any third party? As a user this would be my main concern, and I’ve seen comments like this on other forums when talking about other similar software. Also, I’m kind of new to this setup and was wondering if you know what kind of steps would be needed on the localhost server itself to have a secure enough local server to not get hacked etc.? For example running nginx with certain settings or setting up a strong firewall etc.? Maybe that 2nd question would fall more under the self-hosting category. This looks like a lot of hard work and thanks for creating this to help people.
These are great questions.
how could the user know that their connection was end to end encrypted all the way to localhost
So in the case of boringproxy, by default the client side of the tunnel gets the TLS certs from LetsEncrypt and controls them, therefore neither the boringproxy server nor the VPS it’s running on can decrypt the data (including your username/password in the case of HTTP basic auth). However there’s one big caveat, which is that there’s nothing stopping an evil boringproxy server (or the VPS provider) from getting their own valid certs and using them to intercept the traffic before creating new HTTPS requests to the client. After all, they share the same IP address so LetsEncrypt will happily give them one. In theory, you can protect against this by having the client check at random intervals to make sure the cert being used by the server is actually coming from the client itself through the tunnel. If a different cert is ever provided, you know the server is being evil. I believe LetsEncrypt certs are also public, so you could check the registry to see if there are any unexpected certs.
There are some hairy details here. For example, the server could easily detect when requests are coming from the same IP address as the client, and always server the correct cert in that case. So you might have to use external tools to do the verification. Also, even if you detect the server and stop using it, they may have already stolen very important data.
For these reasons, I like to think of boringproxy as more of a “soft” e2ee system. I think for the vast majority of threat models, it provides very good protections. A lot of e2ee proponents are obsessed with building completely trustless systems. While awesome in theory, I think in practice this rarely results in good UX. boringproxy combines the familiarity and ease-of-use of HTTPS in the browser with reasonably good e2ee guarantees, which I think is a win for users.
Also it’s worth noting that you can achieve strong e2ee with boringproxy. But it would require you to write special software on the client side that verifies the public key of the server with every new TLS connection.
what kind of steps would be needed on the localhost server itself to have a secure enough local server to not get hacked
Honestly, this is not my area of expertise. I could make some suggestions, but I’d recommend searching/asking over at /r/selfhosted for a comprehensive answer.
Maybe that 2nd question would fall more under the self-hosting category
I wouldn’t worry about this too much. In most cases self-hosting is a subset of data ownership. Data ownership is just a broader term. For example if you use a cloud provider to host your data, but you encrypt it so they can’t access it, I feel that you still are exercising ownership even though you’re not hosting it yourself. I may actually end up deleting the self-hosting category, but would be interested in hearing any suggestions you have for category organization.
Ok thanks, that explains a lot! When you get a cert though, doesn’t the connection verify that the domain on the cert matches the domain that was requested? Or they could theoretically get another cert by using a different domain name but the same ip and then after the first initial connection rerouting the traffic to the other domain and other cert, and then forwarding to client right?
When you get a cert though, doesn’t the connection verify that the domain on the cert matches the domain that was requested?
You mean when an HTTPS client gets the cert from a server it’s making a request to?
Or they could theoretically get another cert by using a different domain name but the same ip and then after the first initial connection rerouting the traffic to the other domain and other cert, and then forwarding to client right?
It’s worse than that actually. They can literally get a cert for exactly the same domain names as you, intercept all the traffic, then re-do the requests to your server again over HTTPS.