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@riseup.net wrote:
On 23 Sep 2018, at 04:50, Alec Muffett alec.muffett@gmail.com wrote:
On Sat, 22 Sep 2018 at 19:28, Dave Rolek dmr-x@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 )
- correlation backwards to "Server Side Middle 1" for browsing a normal
onion over Tor; or...
- 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