Trouble configuring HTTPS proxy as man in the middle.

[gorzak]

I have bitten off more than I can chew, as is my style. It's how I learn quickest.

Both the proxy client and server are machines I have full access to. I plan on using the server for content adaptation after I get the proxy thing down. This guy at overclockers forum wants to do something similar, and has even drawn a picture, but gotten no response. Wikipedia's article on proxy servers describes how it can be done, the pertinent paragraph is:

As mentioned above, the SSL/TLS chain-of-trust does rely on trusted root certificate authorities; in a workplace setting where the client is managed by the organization, trust might be granted to a root certificate whose private key is known to the proxy. Concretely, a root certificate generated by the proxy is installed into the browser CA list by IT staff. In such scenarios, proxy analysis of the contents of a SSL/TLS transaction becomes possible. The proxy is effectively operating a man-in-the-middle attack, allowed by the client's trust of a root certificate the proxy owns.

I have been unable to find how to's or tutorials in configuring proxies in such a fashion

Right now the server is squid 3.0 with ssl enabled on debian. As it stands, HTTP going through the proxy fine, HTTPS isn't. My searches on the ssl error messages generated have turned up conflicting instructions that have not aided me. I believe the software is capable of meeting my needs, and it is my inability to properly configure the proxy software that is leading to my problems. I would appreciate pointers either to a resource on how configure a proxy this way or interaction with someone with experience.

Thank you.

[Zeta]

I don't think this is a configuration issue.

You have to hook into the TLS handshake and forge a digital certificate (x.509) of the server the client wants to connect to. That's where you need the above mentioned root certificate: to digitally sign your forgery. You can use it to finish the handshake and get a session key for the connection between client and proxy.

Then you have to establish another connection from the proxy to the server. No problems here. The client doesn't have to prove anything to the server. Here you get a second session key. You have to use these keys to reencrypt all messages between client and server and inbetween you can see the cleartext.

This is not exactly standard proxy behavior. You have to do some real programming here.

[gorzak]

I appreciate your reply Zeta. It is likely I am going to have to table the secure side of this then, until I aquire additional mental tools. I had guessed this would be more common, especially among large corporations that like snooping on employee web habits.