> > > >> 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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
