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

Amos Jeffries squid3 at treenet.co.nz
Fri May 20 09:26:53 UTC 2016


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.

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.

Amos



More information about the squid-dev mailing list