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
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
