[squid-dev] [PATCH] splicing resumed sessions

Wed Mar 25 07:35:42 UTC 2015

On 03/21/2015 07:45 AM, Amos Jeffries wrote:
> On 21/03/2015 10:47 a.m., Alex Rousskov wrote:
>> On 03/20/2015 12:11 PM, Amos Jeffries wrote:
>>> On 21/03/2015 4:35 a.m., Alex Rousskov wrote:
>>>> On 03/20/2015 02:06 AM, Amos Jeffries wrote:
>>>>> On 18/03/2015 6:21 a.m., Tsantilas Christos wrote:
>>>>>> This patch adds the "ssl_bump_resuming_sessions" directive that controls
>>>>>> SslBump behavior when dealing with "resuming SSL/TLS sessions". Without
>>>>>> these changes, SslBump usually terminates all resuming sessions with an
>>>>>> error because such sessions do not include server certificates,
>>>>>> preventing Squid from successfully validating the server identity.
>>
>>
>>> Squid is behaving wrong right now. Fix that.
>>
>> Yes, the proposed patch "fixes that".
>>
>>
>>> I dont see any need for the new directive to exist
>>
>> We can remove the configuration option. The option was added to minimize
>> the chance that you will object to the patch because, without the new
>> option, the old "terminate" behavior would be lost. Clearly, my plan to
>> avoid that discussion has failed! Removing the configuration option is
>> totally fine with me because nobody has asked for it [yet]. We can
>> always add it later if needed.
>>
>>
>>> The validation I'm talking about is the spec requirement that we dont
>>> allow the following scenario:
>>>
>>>    CONNECT example.com:443 HTTP/1.1
>>>    ...
>>>    ClientHello SNI:  example.org
>>
>>
>> I still think this part of the discussion is out of scope, but is there
>> really a spec requirement that talks about comparing CONNECT- and
>> SNI-provided server names? Where? CONNECT is about blind TCP *tunnels*.
>> SNI is about becoming an *end point* of a TLS connection. Those two
>> things seem mutually exclusive to me.
>>
>>
>>> * if the CONNECT and SNI both contain different domains the
>>> specification says SSL "MUST terminate" with a specified reject error.
>>
>> Which specification? RFC 2818 does not mention CONNECT. It contains some
>> requirements for HTTP clients, but Squid is not an HTTP client in this
>> issue scope; Squid is a TCP client.
>>
>
> Sorry the specifics here are mostly in RFC 6066 section 3, the final two
> paragraphs.
>   http://tools.ietf.org/html/rfc6066#section-3
> "
>   If an application negotiates a server name using an application
>   protocol and then upgrades to TLS, and if a server_name extension is
>   sent, then the extension SHOULD contain the same name that was
>   negotiated in the application protocol.  If the server_name is
>   established in the TLS session handshake, the client SHOULD NOT
>   attempt to request a different server name at the application layer.
> "
>
>   ie CONNECT with hostname contains the same value as SNI from the client.
>
> RFC 2818 section 3.1 leads into that with its paragraph 2,
> "
>   If the client has external information as to the expected identity of
>   the server, the hostname check MAY be omitted.
>   ...
>   In such cases, it is important to narrow the scope of
>   acceptable certificates as much as possible in order to prevent man
>   in the middle attacks.  In special cases, it may be appropriate for
>   the client to simply ignore the server's identity, but it must be
>   understood that this leaves the connection open to active attack.
> "
>
> such narrowing can be Squid doing the check that CONNECT == SNI and
> aborting if not.
> My emphasis is in doing what we can to avoid that risk indicated in the
> final line.
>

At the first stages of the ssl bumping , I remember that there was cases 
where the browser used the IP address in CONNECT request and not the 
hostname. I do not know if there are still browsers which uses the same 
form.

I must note that the SSL-bumping is not covered by any RFC.
It is not something it should happen, because IT IS a man in the middle.
The proxy is not expected to validate the client HELLO SNI information, 
with the CONNECT hostname, should not interposed into the client/server 
negotiation.
The browsers can use either the IP or hostname in CONNECT string, 
nothing prevents them for doing this.

>
>>
>>>    - CONNECT having a domain means we are in the RFC 2818 scenario of
>>> TLS-over-HTTP.
>>
>> No, CONNECT means "establish a TCP tunnel by splicing client and server
>> TCP connections together". CONNECT does not imply SSL or TLS. When Squid
>> bumps a secure connection, then Squid becomes subject to various SSL and
>> TLS rules. Here, we are not bumping anything, just splicing at TCP level.
>>
>
> How then does one get into the situation of having a SSL ClientHello
> with a SNI value ... for non-TLS ?
>
>
>>> So ...
>>>   if we allow an admin directive it would be to force terminate when
>>> resume was otherwise allowed.
>>
>> Yes.
>>
>>
>>>   1) Do you have any existing need for that?
>>
>> None other than avoiding this discussion, which has already failed to work.
>>
>>
>>>   2) Would not "ssl_bump terminate blah" be a better way to express the
>>> policy?
>>
>> Probably not. We have considered that design, but most ssl_bump rules
>> rely on information unavailable when sessions are resumed. If we force
>> admins to use ssl_bump to control which resuming sessions are
>> terminated, the ssl_bump rules become needlessly complex and difficult
>> to write correctly.
>>
>>
>>> I think we should fix the currently broken Squid behaviour without a new
>>> directive.
>>
>> Sounds good to me! If we do not hear otherwise, we will commit the
>> proposed patch without the new [already optional] directive.
>>
>>
>> Thank you,
>>
>> Alex.
>>
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>