[tor-project] Launching Ethics Guidelines

[Tim Wilson-Brown - teor]

> On 12 May 2016, at 05:17, Virgil Griffith <i at virgil.gr> wrote:
> 
> On Thu, May 12, 2016 at 9:26 AM, Roger Dingledine <arma at mit.edu> wrote:
>> It puts the relays at new risk. Right now breaking into a rendezvous point
>> is not useful for linking users to the onion services they visit. If both
>> sides are using short circuits, then the rendezvous point is acting as a
>> single-hop proxy. And if we have a design where _sometimes_ the rendezvous
>> point knows both sides, then it becomes a smart strategy to attack it,
>> just in case this is one of those times.
> 
> Okay, That makes a lot of sense.  Okay yes I support that.  If a lot
> of users were using Tor2web and a lot of websites were on single-onion
> services, I totally understand how that makes the middle nodes juicier
> targets for intrusion.  And we'd like to minimize their juiciness.  So
> we need a way for (a) a tor2web user to detect if a domain is a
> single-onion service or (b) a single-onion service to detect whether
> someone is a tor2web user, and then put another hop in the middle.
> 
> I don't know of any way to detect (a).  Maybe someone can enlighten
> me.  For (b), tor2web requests always have a "x-tor2web: true" request
> header.  So the single-onion service could detect that.  It's possible
> that someone will modify their tor2web install to not have that
> header, but it seems sensible simply to forbid that behavior as
> "damaging Tor operators".

I strongly recommend you read Trac ticket #17945 - if it's not clear, let's work on improving it.
https://trac.torproject.org/projects/tor/ticket/17945

Web headers only work for websites, and not for other protocols that use similar mechanisms to tor2web. (Single onion services work for multiple protocols, not just websites.)

Once a web header has been transmitted, it's too late: the introduction and/or rendezvous points already know both the tor client's and onion service's IP address, and traffic is flowing. This increases incentives for running malicious nodes or breaking into nodes or observing and correlating node traffic.

Here's one way this can work:

Nodes can protect themselves from becoming one-hop proxies (exits already do something similar), by rejecting connections where neither side is in the consensus.

Single onion services can advertise their single-hop connections to introduction and rendezvous points in their descriptors.

Then, we can teach tor2web and other one-hop clients to avoid connection failures by creating multi-hop paths to single onion introduction and rendezvous points. (It's best if the client does this, because service connections to introduction points are used for multiple clients, and while clients could tell a service that they want a the service to connect multi-hop to the rendezvous, this would involve a call-based protocol change.)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- 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-project/attachments/20160512/f7c345b6/attachment.sig>