[tor-onions] Probably-stupid question about Circuit IDs

[Mahrud S]

Hi,
In short, yes. I think everything mentioned above is correct, and I'm not
sure what else to add.

Oh, I guess I should ask people NOT to use the "tweak" commit on my
repository, which is also linked in the first email in this thread, as it
actually has a bug (puts a 32bit hex in a 16bit IPv6 section ... smh).
Instead use this: https://github.com/torproject/tor/pull/343 which is
already merged and includes a couple of neat features that I couldn't add
myself, thanks ahf!

ps: Thanks for cc'ing me. I'm trying to limit the number of tor-* mailing
lists that I'm on, but feel free to cc me if needed.

On Sat, Sep 22, 2018 at 9:09 PM teor <teor at riseup.net> wrote:

>
> On 23 Sep 2018, at 04:50, Alec Muffett <alec.muffett at gmail.com> wrote:
>
> On Sat, 22 Sep 2018 at 19:28, Dave Rolek <dmr-x at riseup.net> wrote:
>
>> The circID is scoped under a given connection between adjacent nodes.
>>
>> A relay node maintains a mapping of circIDs for a circuit - mapping the
>> forward and backward circID - for traffic it is relaying.
>>
>> So for a circuit ...
>>    client <-ID_a-> guard <-ID_b-> middle <-ID_c-> exit
>>
>> ... each of the ID_*s are independent, and any node only knows the IDs
>> immediately "adjacent" to it. Each connection (e.g. each client to that
>> guard) has a independent enumeration/allocation of IDs.
>
>
> That is an awesome explanation, thank you ever so much.
>
> If I read that right, to the most that an attacker with observability of
> the Cloudflare IP addresses could get, is either ...
>
> ( using the nomenclature from the diagram at
> https://twitter.com/AlecMuffett/status/926032680055201792 )
>
> 1) correlation backwards to "Server Side Middle 1" for browsing a normal
> onion over Tor; or...
>
> 2)  correlation backwards to "Client Side Middle" for browsing a
> single-hop onion over Tor
>
> Am I correct?
>
>
> I'm not sure what you mean by "correlation backwards".
>
> The Onion Service and the Onion Service Guard (or Single Onion Service
> Rendezvous Point) both know the circuit id sent from the Onion Service to
> the
> proxy. If an attacker controls the Onion Service Guard (or Single Onion
> Service
> Rendezvous Point), then they can correlate backwards to the Server Side
> Middle 1
> (or Client Side Middle) by looking up linked circuit ids on the node they
> control.
>
> The Rendezvous Point is chosen by the client, so it is just as likely to
> be malicious
> as any other node.
>
> That latter seems not very much worse than the information which a
> compromised exit node would be able to obtain ("Browsing Normal Web over
> Tor") although it would be a lot more available when the circID is
> presented to the any backbone observer who can sniff IPv6?
>
>
> This IPv6 address isn't in the IP header of the packets between
> Cloudflare's
> onion service and Cloudflare's proxy.
>
> It's sent inside the TCP (or TLS?) connection between the Tor onion service
> and the proxy instance, as a text header before any other inner TCP or TLS:
> https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>
> If Cloudflare encrypts their onion service to proxy connections (and they
> should), the circuit id will only be known to the onion service and its
> guard
> (or rendezvous point, for a single-hop onion service connection).
>
> Alternately, if Cloudflare hosts its onions in the same data centre as the
> proxies
> they talk to, then the risk of interception is low.
>
> Then, if the proxy strips out this header before sending the request to
> the origin
> site, or connects to the origin site using TLS, then this IP address
> shouldn't be
> visible on the backbone.
>
> Note: some origin sites still use HTTP to talk to CloudFlare:
> https://www.cloudflare.com/ssl/
>
> Also note: the CloudFlare dashboard shows the circuit id to site owners:
> https://blog.cloudflare.com/cloudflare-onion-service/
>
> I can't see how having the actual circuit id is useful to site owners.
> They can't block it effectively, because it's transient.
> (And the same circuit id can be re-used by independent connections.)
>
> These are good questions for Mahrud, who I've CC'd.
>
> T
>
>
>
>

-- 
mahrud <algorithms.jux-foundation.org/~mahrud/blog>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20180923/559b44ff/attachment.html>