Tor and network security/administration

Tue Jun 20 21:21:27 UTC 2006

On Mon, Jun 19, 2006 at 04:25:09PM -0400, Todd Vierling wrote:
> On 6/19/06, Lionel Elie Mamane <lionel at 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.

The user then loses end-to-end encryption with the final server he
want to connect to. That is unacceptable for a whole range of uses. If
a _user_  wants to control browser headers, he can instruct the
_browser_ in what headers to send or not.

Let's suppose the tor exit node does this https-man-in-the-middle
dance. It is not desirable for all connections, so you need some way
for the user to say per connection what whether it should happen or
not. SOCKS doesn't have such a thing in its protocol, so... you use
another protocol and fix all programs on the face of earth to support
it? You do an UI call-back where the tor daemon on the user's machine
pops up a question "should this HTTPS connection get the extra
headers"? So suddenly this daemon needs an UI on every single user on
the desktop of the user. Text if that's what the user is using, X11 if
that's what he is using, ... And on every single desktop of every
logged in user on the system. Wow.

And how do you handle client certificates in there? By very design of
SSL (unless it is _broken_), the tor exit node won't be able to fake
that, too.

And how do you handle the verification of the server certificate? How
do you know which CA's the client trusts?

And even if you have solved all this for SSL, then there is the _next_
protocol that you have to "man in the middle fiddle with". This way
lies madness.

And above all, it still does not solve your problem. Because the
malicious user can choose not to have the additional header added.

-- 
Lionel