[squid-dev] Fake CONNECT requests during SSL Bump

[Alex Rousskov]

On 09/22/2015 11:16 AM, Amos Jeffries wrote:
> 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?


At the risk of getting into another pointless debate about the meaning
of dictionary words, I have to note that bumping steps are as real as
anything else in Squid. No, they are not described in some RFC, but they
could have been, and they are backed by various necessary processing
steps to implement bumping. We could group those processing steps
differently and could add more steps, of course, but that does not make
the existing steps any less "real" or more "abstract" than, say,
http_access or cache_peer processing steps.


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

I do not see it that way. There is no recursion or even [significant]
repetition here. The fact that we sometimes fake CONNECT message is an
implementation detail driven by Squid code and ICAP limitations. The
CONNECT message is just a container to get the information across.


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

The answer is the same as the answer to the "Why have three bumping
steps?" question: Things are usually identical and sane, but real
traffic requires handling exceptions, and the earlier some of those
exceptions are detected and acted upon, the better.

The simplest example is perhaps a real CONNECT that uses an IP address
instead of a domain name, but there are many more.


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

I do agree that, all other factors being equal, using an ACL is easier.
Moreover, I think migrating from extra transaction adaptation steps to
[eCAP/ICAP-backed] ACLs would be the right long-term direction for Squid.


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

Injections and re-parsings are Squid implementation flaws, not an
inherent problem property. Conceptually, they are not important and will
probably/hopefully eventually disappear.


Alex.