[90889] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Tor and network security/administration

daemon@ATHENA.MIT.EDU (Todd Vierling)
Mon Jun 19 16:25:41 2006

Date: Mon, 19 Jun 2006 16:25:09 -0400
From: "Todd Vierling" <tv@pobox.com>
To: "Lionel Elie Mamane" <lionel@mamane.lu>
Cc: "Kevin Day" <toasty@dragondata.com>,
	"Jeremy Chadwick" <nanog@jdc.parodius.com>, nanog@merit.edu
In-Reply-To: <20060619060535.GA607@capsaicin.mamane.lu>
Errors-To: owner-nanog@merit.edu


On 6/19/06, Lionel Elie Mamane <lionel@mamane.lu> 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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

home help back first fref pref prev next nref lref last post