Separate cert retrieval from actual backend request destination

[chrisgavin]

Hi. I was wondering how easy it would be to add an option (or if there already is one that I'm missing) to allow for forwarding decrypted traffic rather than re-encrypting it. What I want to do is take HTTPS requests, decrypt them and then forward them to another server that generates the response, effectively making sslsplit act like a dynamic SSL terminator.

Sorry I can't make a pull request myself, C is not my strong suit.

[droe]

I'm not sure what exactly you want to achieve, since the back-end server is - by definition - expecting HTTPS. Maybe HAProxy can do what you want, terminating SSL? If not, can you be more specific as to what exactly you are trying to achieve?

[chrisgavin]

Sorry if I wasn't clear. I'm looking to send intercepted traffic to a server I control (that expects HTTP) rather than the originally intended server.

I was hoping there would be a way of specifying a proxyspec like so:

https 0.0.0.0 443 netfilter http 10.0.0.1 80

• Listen for HTTPS on 0.0.0.0:443.
• Use netfilter to find real IP address of server, retrieve certificate and generate one that matches.
• Actually forward the traffic to an HTTP server running on 10.0.0.1:80, rather than the real IP.

After looking at the code it seems like this wouldn't be an easy change to make, so I might have to re-think how I can achieve this. Thanks so much for this really useful tool in anycase. If it doesn't come in useful for this particular project I'm sure I will find something fun to do with it in future.

[droe]

Ah okay. Yes, that is not a trivial change. It would require a separation of the retrieval of the certificate from the actual backend request, which is currently handled in the same TCP and SSL/TLS connection. Separation would add a separate second outgoing request (one for cert retrieval, one for the actual response retrieval). Not sure I want to implement this, but I will keep this issue around as a feature request.