[squid-dev] [PATCH] splicing resumed sessions

[Amos Jeffries]

On 25/03/2015 8:35 p.m., Tsantilas Christos wrote:
> 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 covered that. We ignore raw-IP in CONNECT. The vulnerability is when
the client sending false CONNECT URI/domain gets past security
permissions. With raw-IP that does not work nearly so easily.


> 
> 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.

Which is precisely why we should be careful to be well behaved and do
what verification we can to avoid bad behaviour happening over the
proxy. We cannot catch every case, but preventing even some cases is a
good increase in security.


> The proxy is not expected to validate the client HELLO SNI information,
> with the CONNECT hostname, should not interposed into the client/server
> negotiation.


In the case of a CONNECT we are essentially pretending that SSL-Bump was
an Upgrade request:
"
If an application negotiates a server name using an application protocol
and then upgrades to TLS, then the extension SHOULD contain the same
name that was negotiated in the application protocol.
"
(http://tools.ietf.org/html/rfc6066#section-3)

All I am saying is that we should / SHOULD enforce that requirement in
the spirit of the standard even though technically MITM cases are
officially not mentioned by any IETF document.



> The browsers can use either the IP or hostname in CONNECT string,
> nothing prevents them for doing this.

Indeed. Its the hostname vs SNI case we can check and SHOULD do so. The
raw-IP ones we can skip the check. Some nasties will still get passed,
but less than without any checks.

Amos