Hi,
proper@??? 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
