On 6/18/07, Chris Howie cdhowie@nerdshack.com wrote:
zetawoof wrote:
Most open web proxies don't support https. TOR does, but that still doesn't obviate the risk that the server could be spoofed by an exit node. The Wikimedia secure server is using a CACert key; on most web browsers, this generates a warning which is indistinguishable from the warning generated by an endpoint that's performing a man-in-the-middle attack.
That's a pretty well-disguised insult there. (I'm assuming you did not mean it as such.)
Entirely unintentional.
If someone knows how to use Tor, I would think they at least have a clue how to verify a certificate. The warning is only indistinguishable if you either ignore it or are incredibly dense.  Your argument defeats itself.
There's been enough development work on TOR lately - especially on all-in-one packages like XeroBank (formerly TorPark) which make TOR accessible without any significant technical knowledge.
This entire discussion also assumes that any user of TOR would also know about the secure server - which is hardly a given. Indeed, the secure server is hardly documented
To be sure, this is a problem that could theoretically be solved (by getting a proper certificate for the secure server). However, it remains the case that editing Wikipedia through an untrusted connection is unsafe, especially for an admin.
This demonstrates a fundamental misunderstanding of how asymmetric cryptography works.
I'm quite familiar with the processes involved. To be sure, I did misconstrue the nature of the secure server's key - I was thinking of it as a self-signed certificate for some reason, which *would* be extremely easy to spoof. (One self-signed certificate is indistinguishable from another unless you carefully examine its fingerprint every time you connect.)
The attack model I'm concerned about is a malicious user (call him Mallory) whose TOR exit node is configured to redirect all traffic destined for the Wikipedia secure server to a local copy of stunnel configured with a self-signed or CACert certificate and pointed at the secure server. The client negotiates an SSL connection with Mallory's stunnel, which in turn negotiates with the secure server. As long as the substituted certificate isn't noticed by the client, Mallory can read "secure" server traffic undetected.