Re: [tor-talk] Making a Site Available as both a Hidden Service and on the www - thoughts?

[Ben <ben@xxxxxxxxx>]

Hi all,

Thanks for your input!

> I'll try and update https://storify.com/AlecMuffett/tor-tips later with some thoughts.

I'll confess to finding storify pages quite hard to follow at times, but
there's definitely some food for thought in there. Will try and give it
a fuller read a little later

> On the other side CAs should give out certificates for .onion freely
> since only the owner of the private key can make any use for it.

I can think of some nastiness you could probably do if you could get
malware onto a target's machine, and they were connecting via a tor
router (or similar) rather than using SOCKS, but we're getting into a
few if's and but's there (plus, if you've got malware onto their
machine, there are better ways :) )

> But it's insulting to the superior concept of public-key based routing that the 
> certification industry is involved in any way at all.

I agree, but I suppose that we (as an industry) have spent so long
telling people they can't trust a site if there's no 's' that we
probably can't complain too much about people asking for HTTPS.

> When running a HS you don't get *any* clue where the circuit is coming
> from so the off-the-shelf protections may fail.

Yup, basically the scenerio I was envisaging there was that Bob tries to
hammer the site with SQLi and get's "his" IP banned. That IP, of course,
being the IP of my tor client (so, localhost). Alice then comes along
for an innocent read and gets presented with a page telling her she's
been banned.

To be fair, the IP based bans don't offer any protection against skilled
(or very patient) attackers. If you've got an exploit that the protections won't pick up on, you only need the one request - whether that be after a ban has expired (or an IP change) or the very first request you place.


> Tor users may be bothered by *others* seeing their activities, not
> necessarily you. They may be choosing to use the hidden service simply
> to have a better guarantee they are talking to nobody but you. To be
> sure no BULLRUN or other HTTPS MITM has any chance of playing out its
> cards.
>
> Also Tor users may be using more secure Internets by default or habit,
> but still welcome doing business with you. I probably would.

I hadn't actually thought about it in those terms, but you're right.
Maybe blocking off the shop section isn't quite as easy a decision as I
thought.

>> Basically, care would need to be taken to make sure readers aren't
>> accidentally directed off the HS and onto the www site.

A thought that's occurred to me on this one - currently most static
resources are referenced from a subdomain so that the browser can
parallelise a bit more (the setup is much the same way you might push
static resources to a CDN). 

So something's going to need to change there, otherwise you'll be
hitting foo.onion and then requesting static resources from
static1.example.com

That's handled by a plugin at the moment, so my initial thoughts on
working around that are:

Have the reverse proxy include an additional request header (e.g.
'X-ima-onion-user') and then hack on the plugin so it behaves differently if that header is present (either use a second .onion or make sure the references are relative).

Will also need to take that into account if I ever decide to have the
existing reverse proxy in front of the site cache responses.


>> Anyone have any thoughts of what else there is to trip up on?
>
> Scalability may become an issue.

Scalability is definitely my next challenge to think about. One thing
I've scratched down to come back and consider is whether it might be
setting up a (slightly weird) load balancing solution along the
following lines

You -> foo.onion (load balancer)
foo.onion -> 301 bar.onion

Where bar.onion is a mirror, so you might also end up being redirected
to jay.onion. One thing that concerns me about that is the number of
URLs you might end up with (if you hit bar.onion and then post the link
somewhere, what  if I take bar.onion out of service?).  

I'm working on the assumption there that Tor is the bottleneck, of
course, if that can be discounted then it should simply be a reverse
proxy with multiple origins configured.

Will give it some more thought at some point


> Another idea (hat tip to Blockchain.info support) is you can take the visitor's IP address, 
> and at the time of connection, check the list of tor exit nodes (somewhere like here: 
> https://check.torproject.org/exit-addresses ), and if it matches, redirect them to your 
> own .onion site.

That I like as an idea. Does anyone know if Tor Browser warns when
redirecting from a HTTPS site to HTTP (which is how it'll view it). I
know IE historically has, but have just realised I don't know with
Firefox/TB. Might have to check later.


> Don't forget the "decreasing load and reliance on exit relays" benefit,
> in case we arrive in that dismal future where it grows increasingly hard
> to operate exit relays in a diverse and well-dispersed set of locations.

Yes, that definitely struck me as a benefit. Don't think anyone will
notice my traffic drop off the exits, but if enough people set something
similar up, it could potentially be a good saving


Looks like I've some building/testing to do over the next couple of days
then - should keep me out of trouble for a bit 
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk