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

[Georg Koppen]

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

[1] https://w3c.github.io/webappsec-secure-contexts/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20200721/d0a5056d/attachment-0001.sig>