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: Wed Jun 21 13:20:01 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Dzyk1F8qSx+4jVR1Q7txd5OCdQrYdOXiS7OdtuhDU6A13VaORY24/94p5ClwVQsk6nHWs4RjoaikzEfVuMzZjgiQvaIFOR0/0s3ogZbh1m7QL2ryVYUVG+4fplz1jMq0Sw0Ft/gZjW6ma6OCMgb21a+yIg3/h1tRbE813/eDz4Y=

On 6/20/06, Lionel Elie Mamane <> 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

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

-- Todd Vierling <> <> <>