On 6/18/07, Chris Howie <cdhowie(a)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.