Re: [Tails-dev] Removing SSL CA dependency for HTP

On Fri, Jun 08, 2012 at 08:11:31PM +0200, proper@??? wrote:
> intrigeri <intrigeri@???> wrote:
> > I don't believe trust is a binary on/off thing. It's not because
> > entity A trusts entity B for X, that it's safe and reasonable for
> > entity A to rely on entity B for more and more things other than X.
> > E.g. I would not find it a good idea if the Tor project started a free
> > email hosting service. And I'm pretty sure they would not, with
> > good reasons.
>
> Valid point.
>
> Conclusion, if we are going for hidden services, we need more hidden services.
>
> > What makes you think it's harder to impersonate a Tor hidden service
> > than a SSL CA shipped by Debian? Is it that hard to generate a HS key
> > with the same 80-bits fingerprint than an existing one?
>
> SSL CA's:
> - relies on humans doing their job
> - has theoretical flaws
> - has practically been broken, recently!
>
> Hidden services:
> - relies on technology, distributed trust
> - has theoretical flaws
> - were never impersonated, until now.
>
> That's why my bet is on the hidden services horse. If hidden services
> get impersonated in the future, torproject will adapt and fix the
> issue. On the other hand, I don't expect the SSL CA issue to be
> resolved anytime soon.

I have not done thorough research, but reading the design page again
made me stare at this paragraph for a while:

> If using a bridge: your bridge can replay an old (one week old max.)
> consensus, which is used until HTP has fixed the time; not good, but
> probably a compromise we can make. If your bridge also can setup a SSL
> MitM attack against the HTP connections (e.g. the attacker also controls
> a SSL CA shipped by Debian), it can trick you into using this old
> consensus for max. one week, which is much worse.

Does Tor ensure that the .onion address match the hidden service it
reaches? I am not well versed enough in Tor internals to assert that.

Otherwise, it looks like switching to hidden services would open a new
class of attack for bridge users.



I'd like to also say that I feel a bit uneasy with changing how our
current time synchronisation system works. It took several releases
before we got it right and it have not seen any problems being reported
for a while…

--
Ague