Mike Perry: > Nick: >> Quoth Mike Perry: >>>>> Hidden service circuits require ~4X as many Tor router traversals >>>>> as normal Tor exit circuits to set up, and unlike normal Tor exit >>>>> circuits, they are often *not* prebuilt. Once they are set up, they >>>>> still require 2X as many Tor router traversals end-to-end as normal >>>>> circuits. You could easily circle the globe several times to issue >>>>> a single search query. >>>>> >>>>> And all this is to use the Tor hidden service's 80bit-secure hash >>>>> instead of an https cert, along with all of the other issues with >>>>> Tor Hidden Services that have accumulated over the past decade due >>>>> to the lack of time for maintenance on Tor's part? I am not >>>>> convinced. >>>> >>>> This is good to know -- don't promote hidden service versions of >>>> websites (including DDG) when they have an https version, as hidden >>>> services are broken as of now. >>> >>> Right. However, hidden services are still useful in narrow >>> circumstances, even as janky as they are. I think their most compelling >>> usecase is as fully internal TCP-style application endpoints, not as >>> authentication mechanisms for services that already exist on the >>> surveilled Internet, and use it for their communications. >> >> But don't hidden services have the advantage that as there is no >> exit node, the adversary controlling the entry and exit node problem >> goes away? Or am I misunderstanding. I see that in this case the tor >> connection to the website is not likely to be the weak point anyway, >> but I'd be keen to know if I've got this wrong. > > If you're talking about attacks as strong as end-to-end correlation, > then it turns out hidden services have similar weaknesses on that order. > There are a number of points where the adversary can inject themselves > either to observe or manipulate hidden service circuit construction. > > For some recent examples of that, see > http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf. > > Some of those attacks are quite powerful indeed (and many of them allow > the adversary to choose their own nodes for observation!) and it will > take Tor at least a full stable release cycle or more to fix them... > > > In terms of data confidentiality and integrity though, I think it is > probably true that the Tor hidden service trust root is much stronger > than the browser CA trust root, even given the 80bit name hash and > RSA-1024 sized keys (which probably are roughly equivalent to each other > in strength for most purposes). >
I think it also changes how people might begin to start attacking a user - it is not as easy as just throwing up a Tor node, allow and exit and running some general tools. > However, Mozilla is working on supporting cert pinning for https, which > we should pick up in Tor Browser in the next few months. Basically, all > we have to do after that is pin our search provider's actual leaf > certificate in Tor Browser itself, and the https usecase becomes both > stronger than the hidden service case in terms of data confidentiality > and integrity to the actual search engine (who knows what happens after > that, of course), and roughly 4X faster... > However - Tor will not protect users after the exit node - so if there are libnss bugs, the exit or things beyond it may tamper with it. The attack surface is smaller for Tor HS users, I think. > > Still, despite all of this, I still think hidden services have an > important roll to play in Tor. The search engines of today just aren't > the proper use case for them right now. > I'd like to see an omnibox search that allows people to choose - I would especially like it if that one was totally unfiltered, even for porn or other thought crime. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
