Hi,
this is the certificate that I'm using at the moment:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a3:49:9a:ee:ac:75:66:da
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = nobody
Validity
Not Before: Apr 4 11:32:47 2019 GMT
Not After : Apr 3 11:32:47 2020 GMT
Subject: CN = nobody
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d8:fc:85:95:05:42:aa:3c:52:64:a2:02:a2:8d:
c9:86:48:c3:82:b5:1e:4f:8e:c3:7f:fb:6b:9b:2e:
61:39:10:58:09:09:c9:88:e9:c0:d9:16:b4:e7:36:
99:25:57:c6:f2:07:79:67:7b:50:20:a8:60:42:fa:
e1:57:80:9e:e3:08:80:a6:fb:67:b5:25:3f:96:b0:
83:73:35:91:36:cb:d7:7c:06:d6:58:a9:78:36:10:
73:24:af:53:31:c8:a1:0d:89:05:c1:36:55:22:2a:
8b:33:06:5b:07:47:9e:ff:dd:34:a4:5e:ce:56:95:
8c:4f:76:e5:28:f8:9a:49:3d:50:5b:4b:5f:2a:b4:
9c:0d:f4:1e:09:4f:62:64:a2:ee:46:0f:1a:42:ae:
63:92:8c:02:9c:c0:dc:25:d1:d1:b0:ee:a5:fc:66:
20:20:1b:ac:f4:0e:30:ed:2e:27:b9:02:ca:cb:7b:
32:92:4c:6a:c1:58:59:cd:9b:14:3a:c9:76:bd:e1:
06:dc:0d:f6:53:23:45:28:4b:07:8c:3f:6d:e8:6a:
f2:01:c5:73:55:76:d2:cf:36:63:6f:6e:86:49:c5:
20:05:95:db:fb:05:36:17:7d:a5:fb:3f:37:cb:47:
3e:b4:a0:fd:35:e2:e7:31:c9:60:39:17:e9:7a:82:
0b:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
85:A5:3F:F5:8C:88:EA:38:BF:46:42:72:8B:EE:A1:04:B8:FC:E2:D4
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:nobody
On Thu, 4 Apr 2019 at 12:57, Davide Belloni <davide.belloni@xxxxxxxxx> wrote:
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?ThanjsIl gio 4 apr 2019, 12:35 Amos Jeffries <squid3@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users