[tor-bugs] #19859 [Core Tor/Tor]: Expose stream isolation information to controllers

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Aug 9 07:06:08 UTC 2016


#19859: Expose stream isolation information to controllers
--------------------------------------------+------------------------------
 Reporter:  nickm                           |          Owner:
     Type:  enhancement                     |         Status:  new
 Priority:  Medium                          |      Milestone:  Tor:
                                            |  0.3.0.x-final
Component:  Core Tor/Tor                    |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  needs-proposal hidden-services  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by JeremyRand):

 Hey Nick,

 Indeed, this does seem like a complex problem.  For the specific use cases
 that Namecoin has, my guess is that (4) is probably the simplest and
 least-error-prone option.  However, a concern comes to mind: if a Namecoin
 lookup is considered to have the same isolation properties as the stream
 created by the client application that generated the Namecoin lookup, this
 presumably reveals to someone (who?  The exit relay?  A Namecoin P2P node?
 The service being accessed?  All of the above?) that the Namecoin lookup
 and the client application stream are linked.

 Is this a problem?  If the protocol is HTTP(S), then the accessed service
 can already tell that it's being looked up using Namecoin by checking the
 Host header (and if TLS isn't used, then the exit relay can also tell
 this).  If the protocol uses TLS, then the accessed service and the exit
 relay can tell it's being looked up using Namecoin by checking the SNI
 header (although SNI could be disabled for some protocols that use TLS,
 and perhaps a future version of TLS will offer SNI encryption).  If it's
 some other protocol that doesn't have a Host-like header, then I don't see
 any way that the use of Namecoin is inherently detectable.  Since Tor is
 used for arbitrary TCP traffic, I am hesitant to endorse a solution that
 unnecessarily reveals to adversaries that Namecoin is in use, particularly
 since Namecoin usage is rather rare right now and therefore this narrows
 the anonymity set substantially.

 From the point of view of the Namecoin P2P node, looking up a Namecoin
 name doesn't necessarily reveal everything about how it will be used.  For
 example, it normally doesn't reveal what subdomain is being looked up, nor
 does it reveal what record types are being looked up (IPv4, IPv6, TorHS,
 TLSA, SSHFP, etc.).  It's not immediately obvious to me how much of this
 extra data is revealed, and to whom, as a result of the service being
 accessed over the same circuit, but it makes me uneasy without a clear,
 convincing argument that it's safe.

 So, possible solution: offer an operation of the form "make stream A have
 the same isolation properties as stream B, ''except that stream A must
 also be isolated from stream B''".

 Is this modification worth it?  Would it put much extra load on the Tor
 network?  Are my concerns about revealing extra information to adversaries
 justified, or am I being overly cautious about something that isn't really
 a threat?

 Cheers.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19859#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list