> And a follow-up question if I may - how do you verify that the ssl > connection is to the site you want & not something else? eg: > http://www.wired.com/threatlevel/2010/03/packet-forensics/ > What's the defense against that type of attack?
Well if CA's are giving intermediate CA's to adversaries, and those adversaries are issuing certs MITM on the fly in hardware... then yeah, you've got major problems. Same for if the apps are bundling random CA's as trusted. And for CA's issuing certs (same subject, different hash) on demand. The traditional answer to all such things is still: - Verify and enforce the cert fingerprint, ignore the CA stuff. - Verify and enforce the DNS. - Hope your adversaries don't pass on the above attacks and then simply obtain the real cert and redirect your IP traffic to themselves. But you watch your hop count, latency and server particulars right? Then your adversary mimics those, so... The only defense you have left is context, particularly human factors. Whether in real time (a recognized voice, video, data challenge, etc), and perhaps aided by crypto chained back to a former, known good, session (ZRTP, etc). You're not supposed to pass sensitive data unless you know who's on the other end of the channel first. Even via Tor, people who don't have anything to worry about, generally don't have anything to worry about, unless their padlock icon is broken. If your money, etc, is siphoned, with a good icon (via the above weaknesses), and you can't get it back with an affadavit, choose another financial provider. _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
