[squid-dev] [PATCH] splicing resumed sessions

[Alex Rousskov]

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


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

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.


HTH,

Alex.