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