[squid-dev] Changed SSL bump event ordering

[Steve Hill]

On 18/09/17 19:33, Alex Rousskov wrote:

> AFAICT, neither summary is how things should work. The first is missing
> IP-based CONNECT adaptation. The second is missing SNI-based CONNECT
> adaptation. You need just the second one, but both should be there to
> cover typical use cases.
>
> Also, I would expect the first adaptation and http_access checks
> _before_ the first ssl_bump check (as documented at the wiki page
> below), not after it (as shown in your second list):

That's definitely not what I'm seeing.

Looking back, I filed a bug about 18 months ago which is somewhat related:
   http://bugs.squid-cache.org/show_bug.cgi?id=4340
As far as I know that has not been fixed, so for transparent connections 
I would still expect the ssl_bump ACL to happen before http_access.

An update on my previous email: adaptation does still happen (I was 
inadvertently denying it in the adaptation_access ACL).  So having fixed 
that, the ordering I'm seeing now for transparent connection (from the 
debug log) is:

1. ACL: ssl_bump (stage 1) - returns sslpeek.
2. Fake CONNECT to the web server's IP.
3. ACL: spoof_client_ip - returns DENIED
4. *ACL: http_access - returns ALLOWED
5. *ACL: adaptation_access - returns ALLOWED
6. *ICAP REQMOD for "CONNECT <IP>:443" - returns 204 (No modifications)
7. *ACL: cache - returns DENIED
8. sslpeek is performed - ServerBump.cc(27) ServerBump: will peek
9. ACL: ssl_bump (stage 2) - returns sslbump.
10. ACL: never_direct - returns DENIED
11. sslbump is performed- client_side.cc(4447) httpsPeeked: bumped HTTPS 
server
12. client_side.cc(593) logRequest: clientLogRequest: al.url='<web 
server IP>:443'
13: ACL: access_log - returns ALLOWED
14: ACL: ssl_proxy_cert_sign signUntrusted - returns DENIED
15: ACL: ssl_proxy_cert_sign signSelf - returns DENIED
16: ACL: ssl_proxy_cert_sign signTrusted - returns ALLOWED
17: client_side.cc(4173) getSslContextStart: Generating SSL certificate

I never see a faked "CONNECT <sni>:443" and associated http_access ACL 
check and ICAP callout.

I've also now tested this with a non-transparent proxy, making a CONNECT 
to an IP address, and the results are more or less the same with the 
exception that the stage 1 sslbump ACL check happens just before sslpeek 
happens rather than right at the start:

1. CONNECT request parsed
2. *ACL: http_access - returns ALLOWED
3. *ACL: adaptation_access - returns ALLOWED
4. *ICAP REQMOD for "CONNECT <IP>:443" - returns 204 (No modifications)
5. *ACL: cache - returns DENIED
6. ACL: ssl_bump (stage 1) - returns sslpeek.
7. sslpeek is performed: ServerBump.cc(27) ServerBump: will peek
8. ACL: ssl_bump (stage 2) - returns sslbump.
9. ACL: never_direct - returns DENIED
10. sslbump is performed- client_side.cc(4447) httpsPeeked: bumped HTTPS 
server
11. client_side.cc(593) logRequest: clientLogRequest: al.url='<web 
server IP>:443'
12. ACL: access_log - returns ALLOWED
13: ACL: ssl_proxy_cert_sign signUntrusted - returns DENIED
14: ACL: ssl_proxy_cert_sign signSelf - returns DENIED
15: ACL: ssl_proxy_cert_sign signTrusted - returns ALLOWED
16: client_side.cc(4173) getSslContextStart: Generating SSL certificate

All that said, I've looked back at the code for previous 3.5 releases 
and it doesn't look like any of this has changed much (but I haven't 
tried going back and running the old versions to verify how they behaved 
yet).

Anyway, hopefully more debugging today so I might be more enlightened 
later on. :)

>   https://wiki.squid-cache.org/Features/SslPeekAndSplice

In the examples I've given above, steps marked "*" are part of the 
Callout Sequence given on:
  https://wiki.squid-cache.org/SquidFaq/OrderIsImportant#Callout_Sequence

According to the SslPeekAndSplice feature page, the "Callout Sequence" 
steps should be executed twice - once for the unpeeked CONNECT (a faked 
"CONNECT <IP>:443" for transparent connections or the real CONNECT for 
non-transparent), then again for "CONNECT <SNI>:443".  The second 
execution never seems to happen - as far as I can tell, the second 
CONNECT is never generated, the "Callout Sequence" for it is never 
executed and it is never logged.


So from this I think there are 2 separate issues:
1. As described in bug 4340, the step 1 sslbump ACL check happens early 
for transparent connections.
2. A second post-peek CONNECT is never faked.


Thanks for your help - I'll go stare at the code a bit more. :)

-- 
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    sales at opendium.com        support at opendium.com
    +44-1792-824568           +44-1792-825748