[squid-users] Squid 4 ssl_bump issue

[Amos Jeffries]

On 4/04/19 10:11 pm, Davide Belloni wrote:
> Hi,
> I've a problem in Ubuntu 18.04.2 with Squid 4.6 compiled with OpenSSL
> 1.1 about ssl_bump. The same configuration works in Squid 3.5 and
> OpenSSL 1.0
> 
> Here the relevant conf :
> 
>     ...
>     http_port 3128 ssl-bump options=ALL:NO_SSLv3 connection-auth=off
>     generate-host-certificates=off cert=/etc/squid/squidCA.pem
> 

There are several differences which are relevant here.

Firstly, the options= setting in v4 is buggy right now.

Secondly, that "ALL" setting enables a large number of highly unsafe
OpenSSL features. It is not a good idea to use that.

Thirdly, v4 now checks the contents of that squidCA.pem file and only
loads the actually needed cert/key/chain objects. v3 would load
everything even if the cert properties were forbidden for use by a proxy
or HTTP server.



>     # Not bypass server certificate validation errors
>     sslproxy_cert_error deny all
>     # This one return errors with debian on GCP
>     (https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery)
>     host_verify_strict off


The above two directives are setting the defaults. It is only a waste of
CPU cycles to configure that in any Squid version. No need to configure
these at all.

> 
>     sslproxy_session_cache_size 0
> 
>     acl step1 at_step SslBump1
>     acl step2 at_step SslBump2
>     acl step3 at_step SslBump3
> 
>     ssl_bump peek step1 all
>     ssl_bump peek step2 all
> 
>     # API Google
>     acl api_google_urls url_regex
>     ^(https?:\/\/)?.*\.googleapis\.com(:443)?($|\/)
>     acl api_google_urls url_regex
>     ^(https?:\/\/)?.*\.google\.com(:443)?($|\/)
>     acl api_google_urls url_regex
>     ^(https?:\/\/)?.*\.cloud\.google\.com(:443)?($|\/)
>     acl api_google_urls url_regex
>     ^(https:\/\/)?([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})

These regex are overly complex. These two patterns cover the same set of
URLs:

 acl api_google_urls url_regex \
   \.google(apis)?\.com(:443)?($|\/)
   ^(https:\/\/)?([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})



>     acl api_google_ssl ssl::server_name_regex .*\.googleapis\.com
>     acl api_google_ssl ssl::server_name_regex .*\.google\.com
>     acl api_google_ssl ssl::server_name_regex .*\.cloud\.google\.com

Same with these ones:

 acl api_google_ssl ssl::server_name_regex \.google(apis)?\.com


>     acl api_google_ips src 127.0.0.1/32
> 
>     http_access allow api_google_ips api_google_urls
>     ssl_bump splice step3 api_google_ips api_google_ssl
> 
>     http_access deny all
>     ssl_bump terminate step3 all
>     ...
> 
> 
...


> 
> I'm upgrading to Squid4 with OpenSSL 1.1 because with Squid3 Ive some
> connections that get stuck (for example
> https://packages.cloud.google.com/apt/doc/apt-key.gpg) I think for
> unsupported ciphers.
> 
> But with Squid4 and OpenSSL1.1 I've this lines in cache log:
> 
>     2019/04/04 08:49:15 kid1| ERROR: client https start failed to
>     allocate handle: error:140AB043:SSL
>     routines:SSL_CTX_use_certificate:passed a null parameter
> 

Check the SquidCA.pem file actually contains a valid X.509 server CA
certificate and matching key.


>     2019/04/04 08:49:15 kid1| ERROR: could not create TLS server context
>     for local=127.0.0.1:3128 <http://127.0.0.1:3128>
>     remote=127.0.0.1:39203 <http://127.0.0.1:39203> FD 19 flags=1
> 

This must be fixed before any more advanced tests are worth performing.
Their results will be invalid until Squid has an operational TLS context.


Amos