Hi, [email protected] wrote (07 Jun 2012 04:43:20 GMT) : > 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. [1] > [2]
> I think the situation can be improved. > [...] > We have to trust torproject.org. These are the people who give us > Tor. They are not expected to tamper the clock or to exploit the > htpdate phrasing code. (idnxcnkne4qt76tg.onion torproject.org; > p3igkncehackjtib.onion media.torproject.org) 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. > usewithtor ./htpdate -d -q idnxcnkne4qt76tg.onion p3igkncehackjtib.onion > works. Encrypted end-to-end (hidden service). No SSL CA involved. I don't particularly like the SSL CA cartel, but... 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? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
