North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Tor and network security/administration
- From: Todd Vierling
- Date: Mon Jun 19 16:26:16 2006
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=W3EZdPfXXl15FPQl02XzGp+pwvCnkf8S/FuE67yIQQmtToZW6ZMR8JZqOVt1Um0VUxKVl4A1vcKIm+5Eclm4zPjKGb5EbdAPFsnP1JFrNtsbxsQwAUEUo/1/o+JIhC4VDBd/gatTPmU/gEIq3X4phfV9/CuFtkCaRrColq5AucQ=
On 6/19/06, Lionel Elie Mamane <email@example.com> wrote:
You don't do your financial transactions over HTTPS? If you do, by the
very design of SSL, the tor exit node cannot add any HTTP header. That
would be a man-in-the-middle attack on SSL.
Which, for an anonymizing network, could be a deliberate situation.
Tor users are already encouraged to filter through a localhost
instance of a second-stage proxy such as Privoxy. There are other
projects underway to provide similar second-stage proxy services,
possibly capable of functioning as HTTPS m-i-t-m on an intentional
basis. If a user desires to filter browser headers even if
SSL-secured, certainly s/he would know why the "forged" SSL
certificate warning was being presented by the browser.
And there's also the possibility of importing such a proxy's
certificate into the browser as a trusted CA -- at which point the
proxy could generate a "valid" (from the browser's POV) cert for any
All this is an exercise in social vs. technical
vulnerability/security. You cannot fix social vulnerabilities via
solely technical methods, and vice versa.
-- Todd Vierling <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>