[squid-dev] Bumping after peek and Splicing after stare

[Christos Tsantilas]

On 05/20/2016 12:26 PM, Amos Jeffries wrote:
> On 20/05/2016 8:20 p.m., Christos Tsantilas wrote:
>> Hi all,
>>
>>   On peek bumping mode we are sending the client hello message to the SSL
>> server. The client Hello message normally includes the supported
>> features by client and a shared key. This is normally makes impossible
>> to bump the connection after "peek" mode.
>>
>> On stare mode squid sends its hello message (with its supported features
>> and its shared keys), and this is make impossible to splice the
>> connection after stare mode.
>>
>> However currently we are trying to hack openSSL, if it is possible (the
>> same features supported by both squid and client) and fill its internal
>> structures with the hello message sent by client to allow:
>>    - on stare mode splice the connection
>>    - on peek mode bump the connection.
>>
>> This was possible and worked if squid and web client was build using the
>> same openSSL library, or for older firefox clients (which used a limit
>> number of tls extensions).
>>
>> However recent changes to the source code of openSSL, break this
>> feature. Moreover the openSSL source code is significant changed in its
>> trunk repository. The upcoming openSSL releases will have major difference.
>>
>> Looks that it will be very difficult to maintain this hack. And this is
>> already make problems to squid. The stare mode may not work in some cases.
>>
>> The squid code which hacks openSSL is inside adjustSSL function in bio.cc.
>>
>> I am suggesting to just remove this function and the
>> SQUID_CHECK_OPENSSL_HELLO_OVERWRITE_HACK configure.ac check.
>
> Sounds like it is the way to go. It would also be hard to maintain for
> other non-OpenSSL libraries anyway.
>
>
> [Slightly off topic, sorry]
>
> I've said this before, but what I would really like to see in the long
> term is peeking always at clientHello. I dont see any reason not to
> given how BIO works, the action would not involve any crypto and it
> would not lead to the above problem.

This is what fast-sni does! For the step1-to-step2 does not involved any 
openSSL code.

>
> That would solve several problems we have currently:
> * less explicit configurations of step1 actions leading to these problem
> cases.
> * almost all users having to explicitly configure peek at step 1 to get
> the SNI.
> * having to hack up careful http_access configs to deal with the raw-IP
> CONNECT that we start with. Instead jumping straight to the fake-CONNECT
> with SNI details, or raw-IP meaning no SNI.
>   - in other words the CONNECT filters by dstdomain can work without
> having to start ssl_bump.
> * logging and routing of the CONNECT much more consistently being based
> on a domain or server name.
>
> Both peek and stare then reliably mean operations only on the
> serverHello, and Squid can probably start to warn about config issues a
> bit better.

I think, already peek, stare on step1 does not make any difference.
The stare or peek decision is a decision for step2.

But I am not sure that we can completely remove the step1. Splice on 
step1 required for non SSL related protocols.


>
> Amos
>
>