On 5/03/21 1:39 am, Niels Hofmans wrote:
Hi Amos,
Thank you for getting back to me.
So if ssl-bump is required on the http(s)_port directive, I end up at:
https_port simply means TLS is the transport protocol. The transport is
terminated at the proxy. There are many permutations of what is being
done inside that TLS.
So no http_port does not require "ssl-bump".
Squid does not support TLS-inside-TLS encryption layering. Which is why
"ssl-bump" only works for "intercept" or "tproxy" modes on that port
directive.
http_port 0.0.0.0:3128
https_port 0.0.0.0:3129 ssl-bump intercept \
generate-host-certificates=ondynamic_cert_mem_cache_size=10MB \
cert=/etc/squid/ssl/squid.crtkey=/etc/squid/ssl/squid.key \
tls-cert=/etc/squid/ssl/squid.crttls-key=/etc/squid/ssl/squid.key
always_direct allow all
ssl_bump bump all
This however ends up with following logs:
2021/03/04 12:37:43 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on
local=172.17.0.2:3129 remote=172.17.0.1:55508 FD 13 flags=33: (2) No
such file or directory
Which means your NAT systems have no records of port 443 being diverted
to port 3129.
Command to reproduce:
% ALL_PROXY="http://127.0.0.1:3129 <http://127.0.0.1:3129>" curl -k
-vvv --proxy-insecure -X POST --data 'foo' https://ironpeak.be/
<https://ironpeak.be/>
Correct test command for "https_port 3129 intercept ssl-bump" is:
curl --cacert /etc/squid/ssl/squid.crt -vvv \
-X POST --data 'foo' https://ironpeak.be/
This verifies that the system is diverting traffic to the proxy, the
proxy is the TLS agent for those connections, and that connectivity
through the proxy is working.
TLS failure to verify the cert(s) indicate the proxy is not being reached.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
