[squid-users] Squid ssl_bump splice configuration

[Amos Jeffries]

On 30/08/23 07:57, Ben Goz wrote:
> ב"ה
> 
> I managed to get the ssl splice configurations to work but when I'm 
> splicing for example: play.google.com <http://play.google.com>
> 
> I see in cache log the following:
> 
> 2023/08/29 22:54:53.688 kid1| 33,2| client_side.cc(3214) 
> fakeAConnectRequest: fake a CONNECT request to force connState to tunnel 
> for ssl-bump
> 2023/08/29 22:54:53.700 kid1| 33,2| client_side.cc(3214) 
> fakeAConnectRequest: fake a CONNECT request to force connState to tunnel 
> for splice
> 2023/08/29 22:54:53 kid1| SECURITY ALERT: Host header forgery detected 
> on conn3362 local=172.217.22.110:443 <http://172.217.22.110:443> 
> remote=192.168.26.100:55331 <http://192.168.26.100:55331> FD 540 
> flags=17 (local IP does not match any domain IP)
>      current master transaction: master2737
> 2023/08/29 22:54:53 kid1| SECURITY ALERT: on URL: play.google.com:443 
> <http://play.google.com:443>
> 
> The host header forgery issue for play.google.com 
> <http://play.google.com> is observed only for spliced connections, but 
> when this url is bumped I don't see this error.
> Why is splicing making this error?


Likely because splice is emulating a client-generated CONNECT request, 
which then faces the same forgery checks that hits the issues Google DNS 
TTL choices cause with the forgery detection. That is just an educated 
guess though.



> 
> 
> ‫בתאריך יום ב׳, 28 באוג׳ 2023 ב-13:54 מאת ‪Ben Goz‬‏ 
> :‬
> 
>     ב"ה
> 
>     I'm using squid version:
>     nativ at arachimprodsrv3:/usr/local/squid/etc$
>     /usr/local/squid/sbin/squid -v
>     Squid Cache: Version 6.1-VCS
>     Service Name: squid
> 
>     This binary uses OpenSSL 3.0.2 15 Mar 2022. configure options:
>       '--with-large-files' '--with-openssl' '--enable-ssl'

FYI "--enable-ssl" no longer exists.

It was replaced by "--with-openssl".


>     '--enable-ssl-crtd' '--enable-icap-client'
>     '--enable-linux-netfilter' '--disable-ident-lookups'
> 
>     Configured with ssl_bump and tproxy:
>     http_port 0.0.0.0:3128 <http://0.0.0.0:3128>
>     http_port 0.0.0.0:3129 <http://0.0.0.0:3129> tproxy
>     https_port 0.0.0.0:3130 <http://0.0.0.0:3130> tproxy ssl-bump \
>        cert=/usr/local/squid/etc/ssl_cert/myCA.pem \
>        generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>     options=ALL,NO_SSLv3 sslflags=NO_DEFAULT_CA

Use tls-default-ca=off instead of the deprecated sslflags=NO_DEFAULT_CA.



> 
>     And the following configurations:
>     acl NoSSLInterceptRegexp_always ssl::server_name "splice.list"
>     always_direct allow all

The above line tells Squid to never use cache_peer.

Without cache_peer directives to ignore this is just a pointless waste 
of Squid CPU cycles.



>     on_unsupported_protocol tunnel
>     acl DiscoverSNIHost at_step SslBump1
>     ssl_bump splice NoSSLInterceptRegexp_always
>     ssl_bump peek DiscoverSNIHost
>     ssl_bump bump all
> 
>     the content of the file splice.list:
>     .prog.co.il
>     prog.co.il
>     www.prog.co.il

These later two patterns are sub-sets of the first pattern. The 
resulting pattern tree may be producing false negative ACL matches.


> 
>     The tproxy redirections works fine with squid server but
>     unfortunately the urls in splice.list bumped although they should be
>     spliced as seen in the access log:
> 
>     1693219853.255    626 192.168.28.254 TCP_MISS/200 64439 GET
>     https://www.prog.co.il/ -
>     HIER_DIRECT/172.67.196.36 text/html
> 
>     And I see in the browser's certificate viewer my squid self signed
>     certificate.
> 
>     What am I missing here?
> 


Not clear. Maybe adding the TLS SNI, server certificate serverAltName 
field, ssl-bump stage/decision, and Host header (specifically the 
header, not the URI domain) to your log may show something useful.

HTH
Amos