Example hidden service issue

[Drake Wilson]

Quoth "Joseph B. Kowalski" <jbk at hush.ai>, on 2007-03-31 09:31:01 -0700:
> Guys, this, noted in the original post is incorrect:
> 
> GET / HTTP/1.1
> Host: youronionaddress
> 
> 
> When you contact www.google.com, your request goes like this:
> 
> GET / HTTP/1.1
> Host: www.google.com
> 
> 
> You are telling the web server which web site to serve you, using
> the name as an identifier. To clarify, The "HOST" field is not to
> identify you, but to tell the web server you are connecting to 
> which website you would like (Since many servers host multiple
> sites)

By my understanding, here's the chain of reasoning and action:

  1. Someone sets up a foobarbazqux.onion hidden service with the example
     given.  They type in http://foobarbazqux.onion/ to see whether it works.
  2. Browser forwards a request through Tor's SOCKS proxy.  The hostname
     of this request, as far as I know, never gets altered; just that
     onion names won't resolve outside the SOCKS proxy.  Moreover, Tor doesn't
     interpret the HTTP stream at all.  I don't think Privoxy changes the
     former either.
  3. Tor at the other end receives the stream of bytes for the hidden service,
     and passes it onto www.google.com:80.
  4. The original request still contains a Host: header for the onion service,
     since the browser doesn't know what .onion is; it just forwards the hostname
     onto SOCKS.  The Host header can't have been changed to www.google.com in the
     middle, because the only link aware that it's talking to www.google.com is the
     Tor node running the hidden service, and Tor isn't interpreting the HTTP request.
  5. The outgoing connection from the hidden service forwarding is most likely
     not location-anonymized, through Tor or otherwise.
  6. Therefore, Google now has an HTTP request from the public IP address of the
     node running the hidden service, with a Host header corresponding to the hidden
     service.  Therefore, Google now has a reasonable suspicion of where that service
     is located.

As I interpret you, you seem to be rejecting the idea that the Host
header includes anything about the originating browser.  It's true
that the Host header doesn't include anything about the originating
browser, but I don't think the idea that it does ever came up in the
thread, and it's irrelevant to the above chain.

   ---> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070331/3a23aaa7/attachment.pgp>