|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Tor and network security/administration
On 6/20/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. 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 <[email protected]> <[email protected]> <[email protected]>
|