North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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 protected]> 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
remote site.

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 <[email protected]> <[email protected]> <[email protected]>