[tor-onions] [rt.torproject.org #63908] Onion Services & External Resources Hosted On Them

[Tim Wilson-Brown - teor]

> On 29 Jan 2016, at 13:59, Wilton Gorske <wilton at riseup.net> wrote:
> 
> 
> -------- Forwarded Message --------
> Subject: [rt.torproject.org #63908] Onion Services & External Resources
> Hosted On Them
> Date: Fri, 29 Jan 02016 02:19:11 +0000
> From: mk via RT <help at rt.torproject.org>
> Reply-To: help at rt.torproject.org
> To: wilton at riseup.net
> 
> I think you might want to try it on our new ML:
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions.
> 
> On 02016-01-27 23:34:47, wilton at riseup.net wrote:
>> Hello Tor,
>> 
>> I have a question about Onion Services hosting external resources.
>> 
>> If there's a webserver hosted as an Onion Service, with an external
>> resource coded (for instance, a Flickr image on the home page), which
>> 'node' in the rendezvous points system calls that resource? The client?
>> The hidden service? The rendezvous?
>> 
>> It's obviously clear how this works with an exit node on the clearnet,
>> but not so (to me) with Onion Services. I guess it's the hidden service,
>> but that means someone watching the network connection of the service
>> could see it calling the resources for a client every time it was
>> requested. Right?

This question is relevant to operating onion (hidden) service sites and user privacy.

The user's browser makes a request for each resource in the page to the tor client.
The tor client transparently directs requests to site "A.onion" through a rendezvous circuit to the "A" onion service.
It directs requests to site "B.onion" through a different rendezvous circuit to the "B" onion service.
Requests to non-onion sites are directed to an exit that allows that particular domain and port through yet another circuit.

So, onion services never see requests for any other onion service or internet site.
This is ensured cryptographically: an onion service signs a list of introduction points and keys.
Only clients using those keys at those introduction points can get a rendezvous circuit with the service.
(This enables OnionBalance, where an onion site signs introduction points belonging to replica onion services.)

In addition, each Tor Browser URL bar domain is isolated: Tor Browser isolates application-level resources like cookies, and the tor client isolates network-level resources like streams. (This prevents one site spying on what another site is requesting.)

Nevertheless, every client accessing a mixed onion / non-onion page is exposed to all the threats from all the resources loaded by that page. There are also potential fingerprinting and correlation attacks. So, just like pure HTTPS, a pure onion site is best practice.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160129/4dec6f89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160129/4dec6f89/attachment.sig>