On Wed, Jun 08, 2011 at 05:51:41PM -0400, Nick Mathewson wrote:
I'm a little worried about the robustness issue: currently, if an exit node refuses a BEGIN request (because of its exit policy typically) the Tor client will retry at another exit node. But if optimistic data is in use, it seems that the client's initial data will be lost, unless the client keeps a copy around to send to other exits as required.
That's a good point. Perhaps the latter is the right thing to do? That would be sort of a combination of what we do now and the above proposal: buffer the data (as we do now), but also send it (as the proposal). When you eventually receive the CONNECTED, flush anything in the buffer you've already sent. If you eventually receive END instead of CONNECTED, try another circuit, using the buffered data?
Maybe! It seems plausible to me, though we should definitely ponder the security/performance implications.
Indeed. They don't seem bad at first glance, at least.
All I'm saying here, though, is that I'm wondering how hard the change will be to actually make. Most socks client code tends to get isolated in an application's network layer as a replacement for "connect", so unless the application is already set up to do "connect, send send send" rather than "connect, wait for connect, send send send", the application modifications will be tricky.
Right. So it turns out this is a case where using an HTTP proxy makes things easier. Hasn't some Tor person been fiddling with Firefox code? Maybe even Firefox SOCKS code?
As an alternative, the socks proxy (Tor) could be told to say "connected" immediately, so that the app starts sending. I don't know how badly this would break browsers, though. Probably not a good idea.
You also lose the ability to tell the SOCKS client if the connection ended up failing.
- Ian