For work, I often need to see traffic in between a web browser and an HTTP server. I have various client programs that can spit out the headers and request/response information, but recently, with all of IE's quirkiness around cache control, I've found what I really need is a middleman that can show the request/response in between, rather than my own custom HTTP client. That way, I can not only see the traffic, but also see how the browser reacts.

So, essentially, I need a kind of reverse proxy server that can take an incoming HTTP request and forward the request on to another server, then send the response back. Both the request and response should otherwise be left intact. Similar to the "HTTP Tunnel" program that comes with the Apache SOAP toolkit, but I need it to support SSL. So, I would make an HTTP request to server1, and it would make an HTTPS request to server2, the response would come back, and be sent as plain HTTP to server1.

I'm about to piece 3 or 4 things I have already together to make this thing myself, but I was hoping it might already exist out there somewhere. Google hasn't led me to anything yet, so if anyone knows of something like this, let me know. It'd be perfect if it was an easy compile on Solaris and didn't require too much in the way of 3rd party libraries (I do have RSA SSL-C available, though.)

A packet sniffer like Ethereal isn't what you're looking for?

I see how a proxy could be useful for certain things, but if all you want to do is look at traffic once in a while, wouldn't a general purpose sniffer be sufficient?

Not for SSL. If it were that easy to view SSL contents, I'm not sure this whole e-commerce thing would be working out so well...

Oh, duh, silly me. SSL. Of course.

So, just to get this straight, you want an ordinary web browser to make an SSL request of a server, except that server is really a man-in-the-middle that will unencrypt the data, record it, make a new request with the same data to the real server via SSL, receive the response unencrypt and record that, then reencrypt to send back to the browser via the original SSL connection.

I think you're going to have to find an 31337 hacker board for that.

So, when you do write it yourself, keep in mind that you're going to have to do some serious hacking to get the SSL certificates working for you. You're going to have to have the browser know that it's connecting to the proxy, essentially, which may well be in the realm of what you're trying to do, if it's just for test purposes, and you're not trying to intercept real-world communication.

Of course, if you're in control of the ultimate web server they're attaching to, then you have that server's private SSL key, so you ought to be able to decrypt that communication if you recorded it with a sniffer. Then again, I suppose it's possible that you might need the browser's private key, too, if that's how HTTPS works (I forget).

You're misled about what I want to do. I thought I was clear about this, but since it's confused you and Tony both, I guess I didn't explain clearly.

So, just to get this straight, you want an ordinary web browser to make an SSL request of a server

No, I want an ordinary web browser to make an HTTP (non-ssl) request to a man-in-the-middle. That server will open a new *SSL* connection to the target server with the request headers and target URL from the original request. Then the server responds with the request (back to the man-in-the-middle server), and the man-in-the-middle server sends back the request over the normal HTTP channel. Basically, I want to create a virtual connection from the browser to the target server, but I want to see the request and response. The man-in-the-middle server would be configured with the name of the server it's supposed to proxy to, and other than logging the request/response data and translating cookie headers, wouldn't do much with the request itself.

I'm not talking about 31337 hacker tools to decrypt SSL, I'm talking about a simple reverse proxy with the ability to log request/response data before/after sending the request to the target server.

No. You were clear. I'm just an idiot.

However, I don't think I understand what you're trying to do. Is it that you don't have access to these remote HTTPS servers but you still want to see the data transmission for debugging purposes? I made the assumption that something was working via HTTP but failing via HTTPS and you needed to see the difference.

Regardless, I don't think anything like that exists.

I have access to the servers, but I can't just reconfigure them willy-nilly so I can debug them. It involves a lot of red tape, and even when I can, I don't know for certain that what I'm logging is exactly what's being sent out to the client (or being received from the client.) Having a proxy in between would be much more reliable. SunONE Web Server 6.1 allegedly has neat output filter support that would let me do this much more easily, but my mechanisms now (with IWS 6.0) are to insert other debug plugins before the app server, and hope that the app server doesn't munge headers itself (which, of course it does.) I can't log anything after the app server's done its work because the app server plugin returns output to the user and doesn't execute any other plugins afterwards.

I guess I'll have to Frankencode something up, then.

I guess I'll have to Frankencode something up, then.

From your description, it sounds like it might be a useful utility that others could benefit from, so maybe put some work into it so that you can distribute it?

You have to finish/release the current version of Emphatic first though.

Nah, couldn't distribute it as-is because it'd be cobbled together from about 3 or 4 different things I've written for work, and are thus property of my employer. I'd have to re-write it "from scratch" on my own time, which probably won't happen.

Yeah, emphatic needs some work, too. But I'm trying to transition into a new position at work, so people have suddenly realized how valuable I am, and are trying to squeeze every last drop of knowledge out of my brain. Doesn't leave much for empeg time. I'd release now, but there are two bugs that I consider showstoppers, and I'd also like to see the delayed disk write thing fixed in a player release first.

Would you be after something like Achilles?
I tend to use it for demonstrating man in the middle attacks, but it can act as an SSL proxy which allows you to view or alter anything passing through it. Good for web application spoofing attacks as well.

I believe Proxomitron will dump what you want and it works as a browser proxy.

I haven't used it in about a year so I may be wrong.

Ugly, nasty interface but it has some nifty features.

Thanks, I'll give those a shot.