[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Example hidden service issue
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Example hidden service issue
- From: Roger Dingledine <arma@xxxxxxx>
- Date: Sun, 1 Apr 2007 04:43:05 -0400
- Delivered-to: archiver@seul.org
- Delivered-to: or-talk-outgoing@seul.org
- Delivered-to: or-talk@seul.org
- Delivery-date: Sun, 01 Apr 2007 04:43:16 -0400
- In-reply-to: <20070331141221.GA21759@secure.grepular.com>
- References: <20070331141221.GA21759@secure.grepular.com>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Mutt/1.5.9i
On Sat, Mar 31, 2007 at 03:12:21PM +0100, Mike Cardwell wrote:
> In the documentation it tells you to set up an example hidden service
> pointing at google.com, eg:
>
> HiddenServicePort 80 www.google.com:80
>
> I've just started looking at hidden services so I'm not exactly sure how
> they work yet, but if I'm correct, by setting that up and testing it
> surely you'll be connecting to www.google.com on port 80 from the server
> with your hidden service and doing a:
>
> GET / HTTP/1.1
> Host: youronionaddress
>
> Wont that give google a map of Real IP -> Hidden service name?
Yes, you're absolutely right. Oops. Thanks for pointing it out.
I originally split the setup instructions into two steps because
people had a lot of trouble distinguishing whether they had screwed up
editing their torrc or had screwed up setting up their webserver. It's
doubly tricky because we're trying to be platform independent in the
instructions.
One option is to remove step one. This will cause more people to get
confused and send us angry mail that our instructions are too hard.
Another option is to change www.google.com to some other address. But even
if it's a site we really trust (like tor.eff.org), there's still the worry
about somebody watching the site. We could suggest https://tor.eff.org/
instead, because then an observer wouldn't be able to learn the Host:
header (I believe), but that doesn't really resolve the point of failure,
and explaining how to prepend "https://" to the .onion address will turn
the instructions back into a mess.
Any other good options out there? :)
I'm leaning towards option one at this point, simply because instructing
people to point their .onion addresses at an external site is just asking
for trouble -- and suggesting a company that's well-known for keeping
extensive logs is a particularly egregious choice.
Thanks!
--Roger