Tor and network security/administration

Wed Jun 21 17:14:52 UTC 2006

On 6/20/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.

> The user then loses end-to-end encryption with the final server he
> want to connect to.

Depends on your definition of "end-to-end" -- if one "end" is "an
agent on the user's computer", it still fits.  But I think you
misunderstand the reason for a filtering proxy in the context of
anonymizing networks; read on:

> 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.

The reason filtering proxies exist (and are popular with anonymizing
networks) is because most browsers don't provide a deep level of
configurability for this sort of thing.

> 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...

With SOCKS, automated filter control based on IP address (and
hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is
trivial.

> So suddenly this daemon needs an UI on every single user on
> the desktop of the user.

Here's where your misunderstanding is evident.  The filtering proxy is
not at the Tor exit node; it's at the *entry*.

Marrying the UI and the user using the proxy is precisely the point --
the filter is controlled by the person using it.  Thus the UI is
provided to the user who both installed, and is using, the filtering
proxy.  This is typically the way in which e.g. Privoxy+Tor is used,
as Privoxy has no facility for per-user filter settings.

> And how do you handle client certificates in there?

Install the client certs into the proxy agent.

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

Use the proxy agent's UI to pop up the same sort of dialog-box
validation that the browser would traditionally provide.  There happen
to be ready-made code libraries for just this purpose.

> 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.

Filtering proxies target a somewhat narrow scope, but broad use,
subset of possible protocols.  HTTP + HTTPS cover a pretty huge chunk
of traffic and user involvement.  Certainly some other common
protocols could be filtered for anonymizing purposes in their own
ways.

-- 
-- Todd Vierling <tv at duh.org> <tv at pobox.com> <todd at vierling.name>