Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] DuckDuckGo vs Startpage

Jacob Appelbaum jacob at appelbaum.net
Wed Jun 26 01:18:05 PDT 2013


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



More information about the liberationtech mailing list