[squid-users] About SSL peek-n-splice/bump configurations

[Alex Rousskov]

On 09/06/2018 10:18 PM, Amos Jeffries wrote:

> So... (lets call this config A)
> 
> #step1 does this:
> 
>> ssl_bump peek step1 all
> 
> #step2 does this:
> 
>> ssl_bump peek step2 noBumpSites
>> ssl_bump bump
> 
> If the bump at step2 happened, there is no step3.
> 
> #step3 does this:
> 
>> ssl_bump splice step3 noBumpSites

You should also add this to step3 if the bump did not happen at step2
(i.e. if noBumpSites matched at step2):

   ssl_bump bump


> So ... (lets call this config B)
> 
> #step does this:
> 
>> ssl_bump peek step1
> 
> #step2 does this:
> 
>> ssl_bump splice noBumpSites
>> ssl_bump bump all
> 
> Notice there is never any step3, and the splice in this ruleset happens
> at step2.

Correct (assuming noBumpSites matches at step2).


> So config (A) is trying to do a step3 (handshake with server) when it
> has only peek'ed and relayed the clientHello as-is (including any secret
> tokens an unknown features the client is trying to use).

The handshake with the server actually started during step2 (SSL Hellos
were exchanged). The SSL negotiation (if any) completes during step3,
most likely without Squid participation (because Squid is just splicing
at TCP level). If Squid does try to participate in that SSL negotiation,
then it is a Squid bug (see below), and, like you said below, the
handshake will fail because Squid has forwarded client information
without knowing client secrets.


> The bump action is bound to fail.

IIRC, the bump action should be ignored by Squid at step3 because it
becomes banned by peeking at step2. Bugs notwithstanding,
banned/impossible actions should be ignored. Instead, the connections
should be spliced at step3 if no rule matches at step3 because the last
matching rule at step2 was "peek", indicating a splicing intent. Again,
I do not know whether the Squid actually does what it is supposed to do
in this case.


> The config (B) bumps at step2.

It also splices banks at step2. It is possible that the working test
case is spliced at step2 when using config B (and that is why it works).


> Then you can consider what ssl_bump is doing in terms of what info Squid
> has available.
>  step1: TCP IP:port or CONNECT URI (forward-proxy only)
>  step2: TLS clientHello + TLS SNI (if any)
>  step3: TLS serverHello + server cert
> 
> The entire directive set is interpreted from top-to-bottom left-to-right
> each step. First line to fully match is what happens for that step.

Correct.


Cheers,

Alex.