[tor-project] [INFORMATION REQUEST] Onion Service Web Site Deployments

[Matthew Finkel]

On Tue, Jul 21, 2020 at 01:47:40AM +0200, Sebastian Hahn wrote:
> Hi there,
> 

Thanks Sebastian.

> I set up the v2 onion many years ago after playing around with vanity
> URLs briefly mostly as a joke, but people really liked it and then I
> also found a use for it for some tor-only linux systems. That's why I
> also set up a v3 onion a few months ago when light-heartedly pressured
> to do so by the operators of the web site. They have put the following
> disclaimer on their site:
> 
> > This server can also be reached as a (V3) service on the Tor network:
> > http://ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion/.
> > 
> > However, please note that this service is not run by the FTP admins directly on this server, but by someone from the computer-science-department in the same building. That mostly means that your traffic will be travelling unencrypted through the machine doing the proxying and some routers in the building, so you need to trust not only us but also at least this guy. HTTPS is not available for this service (mostly because currently only very expensive EV-certificates could be used for onion-services, there is no 'letsencrypt'-equivalent available). The RRZE FTP Admins cannot influence the running of this service in any way, we do not know how stable it is, we cannot debug it, and so on.
> 
> The university is absolutely not ready to run tor on their mirroring
> system, so I either do it this way or I have no convenient way of
> updating my tor-only systems. People using this service have to check
> signatures of anything they download, as I could have tampered with it
> or the operators of the three switches between the hidden service and
> the website.

This disclaimer is very good. Thanks for describing this deployment.

If onion services like this can't be secured (using something like Ian's
suggestion), then I wonder how Tor Browser can learn that a connection
should not be considered secure. One thought is that we could add
another torrc option (HiddenServiceInsecureExtension 0|1) and tor puts
that information into the onion service descriptor (and Tor Browser
could query this over the control port).

Along the same line, this is relevant when the onion service is operated
by a third-party (and the connection is not end-to-end secure). I don't
know how (or if) Tor Browser should learn about that trust-relationship
and change its behavior. This configuration is similar to a CDN
providing TLS termination, as long as the website operator (or the
client) trust the third-party onion service operator.

> 
> If there were some sensible way to have https which terminates at their
> end while they don't have to operate a hidden service, I am pretty sure
> we could work something out and I would obviously go for it.

I like Ian's example, if that is an option. I see that nginx supports
something similar, too. I can imagine a hacky socat solution, too (but a
reverse proxy is less of a ducktape-and-chewing-gum design).