[squid-dev] [PATCH] sslproxy_options in peek-and-splice mode

[Amos Jeffries]

On 12/02/2015 12:45 a.m., Tsantilas Christos wrote:
> On 02/11/2015 01:54 AM, Amos Jeffries wrote:
>> On 9/02/2015 6:43 a.m., Tsantilas Christos wrote:
>>> Bug description:
>>>
>>>    - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol:
>>>             sslproxy_options NO_TLSv1_2
>>>    - Squid uses peek mode for bumped connections.
>>>    - Web client sends an TLSv1_2 hello message and squid in peek mode,
>>> forwards the client hello message to server
>>>    - Web server respond with an TLSv1_2 hello message
>>>    - Squid while parsing server hello message aborts with an error
>>> because  sslproxy_options deny the use ot TLSv1_2 protocol.
>>>
>>> This patch fixes squid to ignore sslproxy_options in peek or stare
>>> bumping mode.
>>
>> As I understand it the action of applying the options to the context
>> removes from the context cipher references etc which are not possible.
>>
>> Since peek and stare are non-final states I can easily imagine that
>> OpenSSL library negotiates ciphers which the options would otherwise
>> prohibit. Then when the options get applied to the context it find
>> itself using an algorithm which does not exist.
> 
> The context SSL_CTX objects are bases to create the SSL objects which
> are responsible for the negotiation with the other side (server in this
> case).
> The SSL created, inherits the options from CTXa nd we are adding our
> options to SSL object.
> The SSL library will use these options to build client hello message,
> parse server hello message and select algorithms/ciphers and other
> features to establish SSL connection.
> 
> In my patch the options applied to the squid client SSL objects
> immediately after created, in the case of bump-server-first, or
> bump-client-first.
> 
> In the cases of peek or stare we are not setting any options. This is
> because we are sending a hello message which is the same or similar with
> the client hello message, so we can not apply options. Else the peek or
> stare will fail...
> 

What I means is the code flow is roughly like this yes?

1) bump
2) splice
3) peek then bump
4) stare then bump
5) peek then splice
6) stare then splice

In which of those cases are the options set?
 all cases ending in bump or splice.

Also, for this bug to have occured at all means the server SSL_CTX is
being actively used during the peek/stare steps.

So what can possibly go wrong by changing the CTX cipher sets halfway
through case 3, 4, 5, 6 ?




> This is has as result that we can not control the ssl behaviour in peek
> or stare mode. But it is not easy to do anything else...
> Maybe we can add 1-2 new configurations parameter which control the
> behaviour. But this is a different project...

I agree we should do the not-setting-options. What I'm having issues
with is how it appears that they are set later - which could be just
adding a different problem.

Amos