<div dir="auto">Hi, thanks very much for all the advices!<div dir="auto">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 .</div><div dir="auto"><br></div><div dir="auto">Do you have some link to a good howto about that?</div><div dir="auto"><br></div><div dir="auto">Thanjs</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il gio 4 apr 2019, 12:35 Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/04/19 10:11 pm, Davide Belloni wrote:<br>
> Hi,<br>
> I've a problem in Ubuntu 18.04.2 with Squid 4.6 compiled with OpenSSL<br>
> 1.1 about ssl_bump. The same configuration works in Squid 3.5 and<br>
> OpenSSL 1.0<br>
> <br>
> Here the relevant conf :<br>
> <br>
>     ...<br>
>     http_port 3128 ssl-bump options=ALL:NO_SSLv3 connection-auth=off<br>
>     generate-host-certificates=off cert=/etc/squid/squidCA.pem<br>
> <br>
<br>
There are several differences which are relevant here.<br>
<br>
Firstly, the options= setting in v4 is buggy right now.<br>
<br>
Secondly, that "ALL" setting enables a large number of highly unsafe<br>
OpenSSL features. It is not a good idea to use that.<br>
<br>
Thirdly, v4 now checks the contents of that squidCA.pem file and only<br>
loads the actually needed cert/key/chain objects. v3 would load<br>
everything even if the cert properties were forbidden for use by a proxy<br>
or HTTP server.<br>
<br>
<br>
<br>
>     # Not bypass server certificate validation errors<br>
>     sslproxy_cert_error deny all<br>
>     # This one return errors with debian on GCP<br>
>     (<a href="https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery" rel="noreferrer noreferrer" target="_blank">https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery</a>)<br>
>     host_verify_strict off<br>
<br>
<br>
The above two directives are setting the defaults. It is only a waste of<br>
CPU cycles to configure that in any Squid version. No need to configure<br>
these at all.<br>
<br>
> <br>
>     sslproxy_session_cache_size 0<br>
> <br>
>     acl step1 at_step SslBump1<br>
>     acl step2 at_step SslBump2<br>
>     acl step3 at_step SslBump3<br>
> <br>
>     ssl_bump peek step1 all<br>
>     ssl_bump peek step2 all<br>
> <br>
>     # API Google<br>
>     acl api_google_urls url_regex<br>
>     ^(https?:\/\/)?.*\.googleapis\.com(:443)?($|\/)<br>
>     acl api_google_urls url_regex<br>
>     ^(https?:\/\/)?.*\.google\.com(:443)?($|\/)<br>
>     acl api_google_urls url_regex<br>
>     ^(https?:\/\/)?.*\.cloud\.google\.com(:443)?($|\/)<br>
>     acl api_google_urls url_regex<br>
>     ^(https:\/\/)?([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})<br>
<br>
These regex are overly complex. These two patterns cover the same set of<br>
URLs:<br>
<br>
 acl api_google_urls url_regex \<br>
   \.google(apis)?\.com(:443)?($|\/)<br>
   ^(https:\/\/)?([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})<br>
<br>
<br>
<br>
>     acl api_google_ssl ssl::server_name_regex .*\.googleapis\.com<br>
>     acl api_google_ssl ssl::server_name_regex .*\.google\.com<br>
>     acl api_google_ssl ssl::server_name_regex .*\.cloud\.google\.com<br>
<br>
Same with these ones:<br>
<br>
 acl api_google_ssl ssl::server_name_regex \.google(apis)?\.com<br>
<br>
<br>
>     acl api_google_ips src <a href="http://127.0.0.1/32" rel="noreferrer noreferrer" target="_blank">127.0.0.1/32</a><br>
> <br>
>     http_access allow api_google_ips api_google_urls<br>
>     ssl_bump splice step3 api_google_ips api_google_ssl<br>
> <br>
>     http_access deny all<br>
>     ssl_bump terminate step3 all<br>
>     ...<br>
> <br>
> <br>
...<br>
<br>
<br>
> <br>
> I'm upgrading to Squid4 with OpenSSL 1.1 because with Squid3 Ive some<br>
> connections that get stuck (for example<br>
> <a href="https://packages.cloud.google.com/apt/doc/apt-key.gpg" rel="noreferrer noreferrer" target="_blank">https://packages.cloud.google.com/apt/doc/apt-key.gpg</a>) I think for<br>
> unsupported ciphers.<br>
> <br>
> But with Squid4 and OpenSSL1.1 I've this lines in cache log:<br>
> <br>
>     2019/04/04 08:49:15 kid1| ERROR: client https start failed to<br>
>     allocate handle: error:140AB043:SSL<br>
>     routines:SSL_CTX_use_certificate:passed a null parameter<br>
> <br>
<br>
Check the SquidCA.pem file actually contains a valid X.509 server CA<br>
certificate and matching key.<br>
<br>
<br>
>     2019/04/04 08:49:15 kid1| ERROR: could not create TLS server context<br>
>     for local=<a href="http://127.0.0.1:3128" rel="noreferrer noreferrer" target="_blank">127.0.0.1:3128</a> <<a href="http://127.0.0.1:3128" rel="noreferrer noreferrer" target="_blank">http://127.0.0.1:3128</a>><br>
>     remote=<a href="http://127.0.0.1:39203" rel="noreferrer noreferrer" target="_blank">127.0.0.1:39203</a> <<a href="http://127.0.0.1:39203" rel="noreferrer noreferrer" target="_blank">http://127.0.0.1:39203</a>> FD 19 flags=1<br>
> <br>
<br>
This must be fixed before any more advanced tests are worth performing.<br>
Their results will be invalid until Squid has an operational TLS context.<br>
<br>
<br>
Amos<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank" rel="noreferrer">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>