On Fri, Jun 08, 2012 at 08:11:31PM +0200, [email protected] wrote: > intrigeri <[email protected]> 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
pgpDdiU0LDHnh.pgp
Description: PGP signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
