`socks.py` - Firefox Sends Client Data to the SOCKS Control Connection

[dwtj]

As of 1bb7303 and using Firefox's SOCKS 5 proxy support: Firefox is sending the HTTP request to the SOCKS control connection, not the ephemeral relay port. The client is currently ignoring the port that was sent to it

Maybe the interpretation that we settled on in Issue #8 was wrong... :(

[dwtj]

Here is what the message log looks like as of fdc740d

fir:~/School/2014-Fall/CS_309/309Project% ./socks.py
2014-09-10 02:24:22-0500 [-] Log opened.
2014-09-10 02:24:22-0500 [-] SOCKSFactory starting on 1080
2014-09-10 02:24:22-0500 [-] Starting factory <__main__.SOCKSFactory object at 0x1102bd0f0>
2014-09-10 02:24:27-0500 [__main__.SOCKSFactory] SOCKSProtocol: connectionMade()
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] dataReceived(), where `data` == b'\x05\x01\x00'
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] dataReceived(), where `data` == b'\x05\x01\x00\x012\x1f\x97!\x00P'
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] EphemeralRelayPairFactory Constructed
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] EphemeralRelayPairFactory starting on 56897
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] Starting factory <__main__.EphemeralRelayPairFactory object at 0x1102d35c0>
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] reply: b'\x05\x00\x00\x01\x7f\x00\x00\x01\xdeA'
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] dataReceived(), where `data` == b'GET / HTTP/1.1\r\nHost: www.arstechnica.com\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: en-US,en;q=0.5\r\nAccept-Encoding: gzip, deflate\r\nConnection: keep-alive\r\n\r\n'
2014-09-10 02:24:27-0500 [SOCKSProtocol,0,127.0.0.1] Data received from the client, but the `SOCKSProtocol` was already in the `done` state. Going into an error state.

Hopefully this is not how all SOCKS clients work, since this would mean that I have wasted some time. Nevertheless, I would be able to revise socks.py to handle this behavior.

But if this is indeed how some clients work some of the time, then that would be bad: it would make handling all contingencies much more complicated.

[nskinkel]

Can you link to the specification you're using to implement the SOCKS5 proxy? Also, have you checked how it's handled in the "official" SOCKS4a implementation?

[dwtj]

I'm just using the RFC linked to in the wiki. And I haven't figured out how the "official" works.

(I'm sort of expecting that this is some browser-specific performance thing.)

[dwtj]

It turns out that I was wrong in my interpretation of of the SOCKS5 specification. In particular, I misinterpreted the "CONNECT" section on page 6 of RFC 1928. The correct socks proxy behavior is implemented as of f0e5a6b8.