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

[carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>]

On Sun, May 17, 2015 at 11:26:41AM -0000, Ben wrote:
> I've got a (www) site that I'm debating making available as a Hidden
> Service, and I was wondering what peoples thinking on doing this was
> nowadays.

I have a feeling what people think about it isn't always in sync with
a rational/factual thinking approach. Choose which one you prefer.

> It's a publicly available site, so it's not privacy for me (as the
> operator) that I'm looking for by setting up a HS - it's got a

You are however providing better privacy to your viewers.

> reasonable readership and it's occurred to me that it'd be good to give
> readers the option of accessing via a HS so that they can make their own
> choices regarding anonymity.
> 
> Some of the content could be considered controversial in some of the
> stranger jurisdictions of the world, it's not impossible that it might
> even be blocked in some of the even-stranger ones.

So you are providing for some redundancy, that's good.. no?

> The site in question can already be accessed via a tor exit node, but
> that brings a third party into the mix (the exit operator). Although the
> site uses HTTPS there's still always the outside chance. Using a HS cuts
> that out (and frees up a little exit capacity to boot).

Yes.

> So I've been scrawling a few perceived challenges and wondered whether
> anyone can think of anything I've missed (or has suggestions on those I
> haven't?):
> 
> 
> Site uses HTTPS
> -------------------------
> I'll hit this one first as it ties in with some other bits - the site
> uses HTTPS and will redirect requests on port 80 to 443. Obviously the
> certificate is going to be invalid if you're hitting a .onion.

Which is a bug in all browsers including Tor Browser. Onion addresses
are self-authenticating. It is completely useless to expect them to
also be X.509 compliant. In fact it is an insult to a superior
authentication system - after all .onion is more secure than HTTPS.
TLS over HS should be permitted to be utilized freely without certification.

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.
Such a certificate cannot be abused. It proves nothing and has zero 
implications. The certificate credentials could say "unknown website."
A signature from the CA means no endorsement of anything, as with
.onion that just doesn't make sense. But it's insulting to the superior
concept of public-key based routing that the certification industry is
involved in any way at all.

> So, the basic setup I was thinking is to create a reverse proxy for the
> .onion which then sends the requests onto the https main site (same server) with the Host header set to the Site's FQDN. 
> 
> So the HS can be accessed over port 80 without triggering the redirects.
> The Tor client and reverse proxy would be running on the same server, so
> the plaintext bit would be over loopback.

Sounds like a reasonable approach until the web browsers are fixed.

> Duplicate Content Penalty
> -------------------------------------
> 
> If Google crawls the site through the public FQDN, and then manages to
> hit the HS via tor2web (or a similar service) - I'll probably get stung
> in their indexes with a duplicate content penalty. 
> 
> Thinking it might be best to have the HS serve a different robots.txt to
> avoid/mitigate this

Yes.

> Anti-abuse scripts
> --------------------------
> 
> There are some off-the-shelf protections built into the site. Given they
> were designed for the www, they can (and do) ban any IP that's seen as a
> repeat offender. 
> 
> Either an exclusion needs to be made, or the HS will sometimes show
> 'nice' visitors a potentially rude message :)

When running a HS you don't get *any* clue where the circuit is coming
from so the off-the-shelf protections may fail. It would be cool if
Tor was to introduce bidirectionally authenticated circuits - that
would allow for proper P2P apps over Tor - and in your case allow for
users to consciously choose pseudonimity instead of anonymity (by
storing the public key they used to access your site last time).
This allows you as the site owner to apply behavioral ranking logic
to pseudonymous users without annoying them with a registration.

> Whether or not an exclusion is made, things that don't _need_ to be
> available via the HS can be blocked off at the reverse proxy (for
> example management back-ends).
> 
> There are other sections of the site that could, potentially, be blocked
> off to lessen the attack surface available to an adversary - for example
> are you likely to use the shop section (physical items) if you're using
> a HS? You don't want me to see your IP, so it seems unlikely you'd give
> me a shipping address and payment info?

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.

> This is probably the part I'm most undecided on - I don't want to
> un-necessarily restrict access to certain areas, but I also want to make
> sure that the existing protections aren't weakened too much (in case I
> or someone else make a mistake).

I don't know an easy answer to this one...

> Minor Tweaks might be needed
> ---------------------------------------------
> 
> There are some base assumptions that have already been made within the
> site - Javascript has been used sparingly if at all, but setting up a HS
> brings a few extra (potential) complications.

Javascript isn't one of them. HS are more authentic than HTTPS or
HTTP websites. Javascript on onions is dangerous only if you are looking
for the nasty dangerous places out there, but if the onion is known to
be run by a legally sueable entity it makes sense to have a lot more
trust for Javascript that cannot be modified by men in the middle.

> All (internal) URL references will need to be relative - including the
> URL's issued in redirects (where applicable).

Yes.

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

Yes. Facebook engineers made quite a thorough job fixing all the
internal linking up and distributing the load to a cloud of onions.
Luckily, their business model depends on you logging in, not so much
on knowing your current IP address - but I'm not saying Facebook is
any better than any other corporation fulfilling the requirements
of the free, outlawed and anti-constitutional Internet market.

> Sessions won't be transferable
> -------------------------------------------
> 
> This is a good thing in my book, but if a user hits (for example) the HS
> first and then visits the www site (for whatever reason), the domain
> name will have changed so the session cookie won't be sent.
> 
> That's not a bad thing, but to avoid getting dinged with support
> requests, probably worth making very clear somewhere on the site.
> 
> 
> Analytics Could Get Fun
> -----------------------------------
> 
> This one won't affect me, but as I'll include it anyway - any back-end
> analytics software based on source IP will (potentially) show a lot of
> traffic/hits from a single IP. Depending on how popular the HS option is
> (i.e. how many who were accessing via www switch to the HS) it might completely invalidate the data (though the same can be said, to an extent for anyone coming via an exit node).

Yes.

> Potentially helping an adversary
> ----------------------------------------------
> 
> This is a pretty minor thing, it's more a point of principle than
> anything.
> 
> By having a service available over both the www and a HS, my site
> becomes a potential target for anyone looking to test a method of
> identifying where a HS is hosted (as they can verify their findings
> against the www service).
> 
> Now, obviously, there's no reason they couldn't set up their own service
> to do the exact same thing, it's more the principal of not wanting to
> help someone de-anonymise.

By declaring yourself the owner of that .onion you already de-anonymized
yourself. Your visitors are not affected by you having two websites.
In fact you could consider removing some extra hops by using the
so-called tor2web mode.

> It goes without saying that the server won't be hosting any HS that are
> intended only to be HS's. 

Actually the presence of a popular hidden service may provide for
excellent cover traffic for any further hidden service. After all,
if I'm well educated, the other hidden service should be having
a completely different spot in the hashtable, completely different
rendez-vous points, completely separate circuits. The fact that it
runs the last mile together with the main hidden service only makes
it harder to detect. But maybe I'm wrong here.

> I'll probably look at setting a HS up with authentication required for
> testing, but I'm trying to think it through first to avoid dropping a
> bollock. 
> 
> What I definitely don't want to do is set up, announce and then find
> I've missed something and have to disable the HS until I can fix the
> issue :)

Enough to only start telling a few people. Activing the HS will give
you time to get accostumed to the robots that hunt down any new
hidden service that shows up in the hashtable.

> Anyone have any thoughts of what else there is to trip up on?

Scalability may become an issue.


-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion		DON'T SEND ME
          irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
         http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE
-- 
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