[squid-dev] [PATCH] splicing resumed sessions

[Amos Jeffries]

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.
> 
> 
>> The RFC 2818 has mandatory validation of the HTTP CONNECT, client SNI
>> (with server ack), and server certificate dNSname values before session
>> resume may be performed.
> 
> 
> I am afraid you have misunderstood the problem domain because RFC 2818
> is irrelevant here. That RFC is about sending HTTP over TLS. Here, Squid
> does not establish a secure HTTP connection with the client or server so
> Squid is not subject to that RFC (the client and server are).
> 
> Without the patch, a client and server cannot resume secure sessions.
> Users suffer from disconnects and various associated errors even though
> Squid does not bump their connections. With the patch, things work, and
> work without violating any TLS/SSL rules. Moreover, an admin can now
> explicitly control whether resumed sessions are allowed or not (the
> default "allow" is what nearly everybody should want).


Squid is behaving wrong right now. Fix that.

I dont see any need for the new directive to exist because Squid should
be resuming by default and terminate the SSL only when the domain checks
which are possible confirm bad behaviour.

It sounds a bit like a "fail open", but is actually an opportunistic
terminate [see below].


> 
>> I dont think we have any such validation in Squid yet. So the current
>> behaviour of terminate is mandatory for compliance with TLS.
> 
> 
> As Christos has said, proper validation is impossible in this case even
> if we wanted to do it: Squid most likely have already spliced the
> previous TLS session (a compliant behavior!) and now does not have
> enough information to validate the new connection to the server (because
> the server does not send its certificate during session resumption) and
> splices the connections again.
> 

I think we are talking past each other here again, and again its the
word "validation". Previous connection has nothing to do with it. HTTP
messages inside the previous connection have nothing to do with it.

> HTTP, TLS, and SSL RFCs do not apply to traffic on spliced connections.
> When splicing, Squid works as a TCP proxy. The fact that Squid may have
> peeked into the connections (before deciding to splice them) is
> irrelevant because that peeking did not affect the security of those
> connections.


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


* if the CONNECT contains a raw-IP we can ignore it.
 - this includes our fake-CONNECT on intercept.

* if the SNI is missing we can ignore it.

* if the CONNECT and SNI both contain different domains the
specification says SSL "MUST terminate" with a specified reject error.

  - CONNECT having a domain means we are in the RFC 2818 scenario of
TLS-over-HTTP.

  - checking and terminating ourselves helps protect naive/old servers
against SNI abuses.

  - given what Squid is doing, we are allowed to just splice always and
let the endpoints do the error stuff. BUT, that is a waste of resources
when we could abort early and log a nice alert.

In all other cases we can allow the splice to resume with no loss of
safety. The endpoints will do (or not) anything they would do anyway
without the proxy.


So ...
 if we allow an admin directive it would be to force terminate when
resume was otherwise allowed.

 1) Do you have any existing need for that?

 2) Would not "ssl_bump terminate blah" be a better way to express the
policy?


I think we should fix the currently broken Squid behaviour without a new
directive.

Amos