[squid-dev] Fake CONNECT requests during SSL Bump

[Amos Jeffries]

On 23/09/2015 4:32 a.m., 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,

You do understand that those "bump steps" are an abstract concept we
created out of thin air right?
 Every time adaptation completes the adaptation response is re-parsed
and the bumping procedure is re-started from scratch on the TLS which is
contextually now "inside" the new faked-CONNECT.

Its like doing a full ICAP transaction to represent sending a message to
ICAP, then doing a second full one to represent receiving the message
back from ICAP. Then wanting an ICAP request to represent sending that
request to ICAP... Turtles all the ways down...


> 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)

There is a mandatory host == sni identical values thing going on. So why
bother faking a request that will be identical sans the mime headers to
the one preceeding it?

> CONNECT <host>:<port> HTTP/1.1 (initial real CONNECT)
> CONNECT <host>:<port> HTTP/1.1 (step 2: after peeking in step 1)


> 
> 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.

Its not. External ACL is the correct way to do it. A simple helper
lookup that returns a value mid-way through the ssl_bump decision making.

Versus injecting data into the buffer and re-parsing everything from
scratch as a sub-context nested inside the older context(s) from earlier
cycles of CONNECT.


>  Ideally the step 2 CONNECT would contain all of the headers from
> the real connect in the case of a non-transparent connection.
> 
> 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.

fakeAConnectRequest() only injects an HTTP message into the TCP read
buffer. That message is then treated as if *it* were the HTTP message
received instead of straight TLS. It now happens to contain the client
TLS, ... which gets bumped... and so on.

> 
> So I'm looking for some advice on what the best way is to go about doing
> this.  Any advice would be appreciated.
> 

Amos