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

[Ben <ben@xxxxxxxxx>]

> > 
> >> As observed elsewhere, we tell our infrastructure that any traffic inbound
> >> from the Facebook onion site is sourced from the DHCP broadcast
> >> network (169.254/whatever).
> > 
> > [â]
> > I'm assuming you're pushing an IP in that range into the X-Forwarded-For
> > header?
> 
> Approximately yes; we use a different header (extant, internal) so we
> can mostly not mess with the existing headers.

Are you doing anything the maximise the effect that (say) a ban based on
IP can have?

Say for example, I insert a 'unique' IP into a header on a per
connection basis - that'd ensure the ban is effective for the length of
the HTTP keep-alive session (i.e. until my attacker closes or times
out). 

They could, of course, create a new TCP connection as soon as they
realise they've been banned, which would circumvent that.

Have you made any changes lower down (similar to the patch str4d posted,
i guess) so that you can do it on a per-circuit basis (making things a
little harder)

I'm not overly worried about it, IP based bans aren't particularly hard
to circumvent on the www. anyway, but it's piqued my curiosity to think
about different ways you could go about doing it. 

Per client->reverse proxy connection is probably the best you could do
at the HTTP server level I guess, and per Proxy->Origin would risk
inconveniencing others (if the proxy re-uses a connection in the pool to
go upstream).


> > Without wanting to start a thread-in-a-thread, I've definitely got mixed
> > feelings on that one. I think most sites should be using HTTPS, but I
> > think there are also cases where HTTPS genuinely may not be
> > needed/desirable.
> 
> I agree that sometimes itâs overkill.  Iâm okay with an occasional bit
> of overkill in this area.
> 

It depends, here's a massively oversimplified example

- Content served: Feature films
- Format: HLS (2 second segments)
- Max Requests per keepalive session - 300

Admittedly, that keepalive setting isn't ideal anyway, but it'll work on
port 80 (and keeps the maths easy for me) - the connection gets torn
down every 300 requests and then you re-establish.

Switch to HTTPS. 

Every 300 requests, the connection is still torn-down by the origin but
now you have to redo your SSL handshake etc. With VoD that's once every
600 seconds (as you only need to retrieve the manifest once). 

With linear video, it could be far, far more frequent, as you'll be
re-retrieving the manifest regularly.

If we switch from HLS to Smooth Streaming, it gets even worse - we've
now got double the number of requests per fragment because the audio
fragments are delivered separately.

Whether you notice the additional cost of re-establishing will depend
entirely on how many clients are connecting at once of course, but it's
quite a jump to take if the only reason you have SSL is because it's
being mandated by the user-agent.

There are, of course, tweaks that can be made (like upping that
keep-alive limit) to mitigate, but; 

the point I'm trying to make is that people tend to assume that the
traditional overhead of SSL is largely negated by the power of the
systems we use now, but there are definitely areas where that assumption
might be incorrect. 


> The title says "making a site available ass both a HS 
> and WWW". I choose to ignore the deployment 
> complexity and roll-my-own solution, not ask for reason 
> for why I might want both.

So, to summarise, you're saying my original post was tl:dr?

There was an element of "is it a good idea" but the aim was more to
examine the complexities and checking that I was mitigating what could
be mitigated. 

It was definitely never intended as a 'Why would I want both', that one
I've already answered (and was included in the first post [0])

The first question asked was

> 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?):

So I fear you may have mis-understood my intentions when starting the
thread


[0] - https://lists.torproject.org/pipermail/tor-talk/2015-May/037816.html
-- 
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