[squid-dev] Fake CONNECT requests during SSL Bump

[Alex Rousskov]

On 09/22/2015 10:32 AM, Steve Hill wrote:

> Currently, Squid generates a fake CONNECT request for transparently
> proxied HTTPS, and possibly a second fake CONNECT if that connection is
> spliced.  For non-transparently proxied connections, there's a real
> CONNECT, so the first fake CONNECT isn't needed, but the second fake
> CONNECT is also suppressed.
> 
> I'm trying to extend Squid to generate an ICAP REQMOD request for each
> ssl bump step, for both transparent and non-transparent connections.
> i.e. for transparent connections the ICAP server would see something like:
> CONNECT <ip>:<port> HTTP/1.1     (initial fake CONNECT)
> CONNECT <sni>:<port> HTTP/1.1    (step 2: after peeking in step 1)

> and for non-transparent:
> CONNECT <host>:<port> HTTP/1.1 (initial real CONNECT)
> CONNECT <sni>:<port> HTTP/1.1 (step 2: after peeking in step 1)

Makes sense to me. The CONNECT request is needed, in one form or
another, for both ACL- and ICAP-driven solutions, for transparent and
forward-proxy scenarios.

Note that <host> may be <ip> in the forward-proxy scenario too.


> The idea is that the ICAP server can examine the request and add headers
> to tell Squid whether to peek, bump, splice, etc. at each step.  The
> alternative is to use an external ACL do to this, but that seems more
> messy.

Yes, especially if you have to duplicate or split your business logic
between the ICAP service and the external ACL helper. And if you need
extension CONNECT headers that the external ACL is not supposed to get.



> Originally, I thought I could extend fakeAConnectRequest() to handle
> non-transparent connections and use that, but it seems fraught with
> problems - e.g. I end up with a second connection to the web server, and
> generally odd behaviour which is probably the result of the SSL-bump and
> tunnelling code fighting over the same client connection.
> 
> So I'm looking for some advice on what the best way is to go about doing
> this.  Any advice would be appreciated.

It will be difficult. ConnStateData::fakeAConnectRequest() is a big
hack. Extending that to work for forwarded connections is probably
possible, but you would have to carefully compare transparent and
forwarded sequences of calls/events and make sure the forwarded code
works/cleans up as expected.

I would not be surprised if it would be easier to completely remove
fakeAConnectRequest() and implement the whole thing the "right way":
Instead of injecting data into the input buffer, the SslBump code should
be creating CONNECT request structures, and the processing code should
accept CONNECT request structures instead of raw buffers. It was too
difficult to do that earlier, but tunnel.cc is getting better, and may
now allow for the proper implementation.


There is an alternative, but it is also complex: We need to add an
eCAP-backed ACL (headers-only). If you have that, you could put all your
business logic into an eCAP adapter and use that for ssl_bump ACLs
(among other things).


Alex.