On Mon, Jun 19, 2006 at 04:25:09PM -0400, Todd Vierling wrote:
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.
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