[squid-users] Squid 4 ssl_bump issue

Davide Belloni davide.belloni at gmail.com
Thu Apr 4 10:57:43 UTC 2019


Hi, thanks very much for all the advices!
About the action to generate the certificate I've followed the squid wiki,
that doesn't modify (if I remember correctly) openssl conf to create it .

Do you have some link to a good howto about that?

Thanjs

Il gio 4 apr 2019, 12:35 Amos Jeffries <squid3 at treenet.co.nz> ha scritto:

> 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
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190404/704784b8/attachment.html>


More information about the squid-users mailing list