search

droe / sslsplit

Transparent SSL/TLS interception
https://www.roe.ch/SSLsplit
BSD 2-Clause "Simplified" License
1.74k stars 328 forks source link

Optionally enable GZIP encoding with sslsplit #129

Open tracycodes opened 8 years ago

tracycodes commented 8 years ago

It appears that sslsplit by default strips all "Accept-Encoding" headers preventing content encoding features from working. This can create a problem for some misbehaving web servers and prevents SSLSplit from being truly transparent.

Is it possible to add functionality to optionally enable gzip. I know this would likely cause the log to contain binary content, but that can be handled by a third party implementor who parses this log.

Thoughts?

droe commented 8 years ago

SSLsplit is transparent in that it doesn't operate as a proxy configured in the client (browser) but instead intercepts regular connections from the network.

Does using an ssl proxyspec instead of https work for your use case perhaps? In that mode there are no modifications of the transmitted data.

droe commented 8 years ago

Also, can you be more specific on the «problems for some misbehaving web servers» that you mention?

tracycodes commented 8 years ago

Unfortunately ssl proxyspec will not work for us (if my understanding of the code is correct) because our objective is to capture HTTP Application data inside SSL. We process the HTTP connections from a named pipe. It appears as though the primary purpose of using the HTTP proxyspec is to eliminate HSTS and HPKP headers, both are necessary for our application.

In this particular case a web server that a user is connecting with required GZIP encoding to function properly. While I agree that the server should be modified to work in either scenario, some of these problems exist in the real world and since the majority of browsers Accept-Encoding: gzip by default they are easily ignored.

What problems does keep the Accept-Encoding header intact introduce? It seems to shortcut the extra processing overhead of unzipping the content, any other concerns?

droe commented 8 years ago

No concerns except for the not human readable raw logs produced by sslsplit; postprocessing can fix that. To answer your question: the raison d'etre of the HTTP mode was originally just disabling connection persistency, chunking and pipelining in order to get away with a simplistic HTTP 1.0 style parser. Secondary functionality was to produce readable logs by disabling compression. HSTS and HPKP countermeasures came much later down the road.

Does changing "Accept-Encoding: " to "XXXXXX-Encoding: " in the strncasecmp() in pxyconn.c help in your use case? I'd like a confirmation that this is sufficient for your use case before I add yet another flag to the already sizable collection of option flags.