Hi there,
On 21. Jul 2020, at 00:44, Matthew Finkel sysrqb@torproject.org wrote:
(tl;dr: We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that connections with all onion services are secure. Do you send HTTP (unencrypted/unauthenticated) traffic between the onion service and a remote web server?)
I operate multiple such onion services, two see public use and some don't. I will ignore the private ones here.
The two public ones are addresses for my university's ftp mirror, https://ftp.fau.de and they are fauftpffbmvh3p4h.onion (v2) and ftpfaudev4triw2vxiwzf4334e3mynz7osqgtozhbc77fixncqzbyoyd.onion (v3).
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.
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.
Cheers Sebastian