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.
Exactly. At the end it boils down to trust that the server side operator does not mess up things. I don't think there is anything a browser can do about that which is reflected in ways the specifications are written. If you take the secure context specification[1], as it is relevant here, then you see the secure context does _not_ depend on how the server-side setup looks like in detail (e.g. whether there are ways that the traffic travels over plain HTTP after TLS got terminated).
Georg