SockSpy is an application that acts as a network proxy but displays the data as it passes through the application. SockSpy can be configured to forward data from one port to a target port possibly on another machine. Or it can act as a HTTP proxy, listening for HTTP requests and then making the necessary connections. Or it can operate as a SOCKS4 proxy. I all cases once the connection is made to the target socket, all data is copied across the proxy and displayed on screen. SockSSpy may be run using Tk to obtain a graphical user interface or without to just print to a terminal.
Authors of this application have been Tom Poindexter, Keith Vetter, Don Libes and Pat Thoyts.
2009-12-03 SockSpy is SourceForge hosted project. See http://sourceforge.net/projects/sockspy for file downloads and bug reporting. The current version is 2.6 which has various bugs fixed and containts the following list of features.
Features
JMN 2003-07-01 Sometimes it's handy to be able to point an HTTP user-agent at sockspy without having to configure the sockspy address as the user-agent's proxy. The problem with 'fixed server forwarding' as it stands is that, not being specifically for HTTP, it doesn't allow you to connect to the correct virtual server on a webserver that relies on the HTTP Host header to direct requests.
Fixed server forwarding is fine as it is however, for viewing many other protocols such as SMTP, POP3 or whatever. What's needed IMO is another option specifically for HTTP that either adds a Host header, or rewrites the existing one.
Assuming this would be straightforward - I leapt in and started coding. Unfortunately, to do this robustly, sockspy needs to now have a proper concept of the parts of an HTTP request so that for example it doesn't rewrite a line in the body that coincidentally looks like an HTTP Host header line. Having a concept of HTTP requests means sockspy has to look for headers such as 'Content-Length' to determine if there is a body and how big it is.. assuming it's not using chunked encoding. I've managed to massage an experimental version into shape, that I find useful, but it's a bit unpolished and doesn't yet handle the chunked encoding of a request body.
If anyone is interested in this addition, or if it's something that should be added to the project, email me at [email protected]
AK: When I used sockspy to debug some Cookie problem I noted that it does rewrite Set-Cookie and Cookie HTTP headers.
JMN: I'd be surprised.. can't see a mechanism for it in the code. Are you sure there wasn't a transparent proxy of some sort upstream from it? Sockspy seems to just do a straight pass-through from one socket to another, just echoing the conversation to screen with no interference to the stream - which in most cases is what you want.
Actually there's also a problem with the current HTTP proxy support in sockspy 2.5 anyway. It only grabs the destination URL at the time of the client's initial connection - but for a persistent HTTP/1.1 connection, the destination needs to be extracted from each new request-line in case the user has clicked off to another site, or even to display images linked from another site.
Another problem is that a browser may open multiple connections, (not supposed to exceed 2 for HTTP/1.1). Sockspy's output window currently doesn't differentiate between connections, so you can't necessarily tell the difference between a pipelined request on a single request socket, and concurrent requests on 2 request sockets. (except that sometimes you'll see the two requests impossibly interleaved, so you know there must be multiple connections)
I tried outputting the IP/Port combination to the left of the timestamp, but this starts to make the window look a little cluttered. A short numeric connection instanceID would probably be better, maybe with a hyperlinked key somewhere so that you can see the connection info?
AK: I got my sockspy as starkit from the sdarchive. It might be different than yours. The browser was IE. The webserver a tclhttpd I had started myself. Sockspy on the same machine as the server, pointed to it. The browser was pointed directly to the port by sockspy. Tclhttpd got the correct cookies, and the sockspy log showed that sockspy got them a bit different, geared for it as server. So it had to rewrite them. I used cmdline mode btw., no windows.
jmn: Most servers don't seem to explicitly set the domain in their cookies, in which case cookies should work just fine with a sockspy intermediary with no rewriting required. Can you define 'got them a bit different'? I downloaded the sdarchive version and the relevant code looks much the same. The only thing I can think of that you might be seeing, is that if prior to using sockspy your browser had already been issued cookies for that server, then when you put sockspy into the request path, the browser will no longer recognise the server as the one that issued the cookies, and so won't present them - thus the server will issue a new set. Does that seem plausible?
Sebastian Wangnick has an interesting complement to sockspy he calls ipc. [Also explain relations to sniffers--tcpdump, ethereal, ..., and pktsrc ] [Also moni.]