[squid-dev] Bumping after peek and Splicing after stare
christos at chtsanti.net
Fri May 20 11:12:22 UTC 2016
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
> That would solve several problems we have currently:
> * less explicit configurations of step1 actions leading to these problem
> * 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.
More information about the squid-dev