On 2015-12-29 07:46, Eugene M. Zheganin wrote:
Hi.
I'm still trying to figure out why I get certificate generated for IP
address instead of hostname when the HTTPS traffic is intercepted bu
sllBump-enable squid. I'm using iptables to do this:
rdr on $iifs inet proto tcp from 192.168.0.0/16 to ! port 443
-> 127.0.0.1 port 3131
rdr on vpn inet proto tcp from 192.168.0.0/16 to ! port 443 ->
127.0.0.1 port 3131
and the port is configured as follows:
https_port 127.0.0.1:3131 intercept ssl-bump
cert=/usr/local/etc/squid/certs/squid.cert.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
dhparams=/usr/local/etc/squid/certs/dhparam.pem
https_port [::1]:3131 intercept ssl-bump
cert=/usr/local/etc/squid/certs/squid.cert.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
dhparams=/usr/local/etc/squid/certs/dhparam.pem
This way I'm getting a waring in browser (https://youtube.com is opened
in the example below):
===Cut===
youtube.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is
unknown.
The server might not be sending the appropriate intermediate
certificates.
An additional root certificate may need to be imported.
The certificate is only valid for 173.194.71.91
(Error code: sec_error_unknown_issuer)
===Cut===
And the tcpdump capture clearly shows that client browser did sent an
SNI:
https://gyazo.com/c1ba348fb4ee56c6c30f3e22ff9877f8
I'll apreciate any help.
You have ssl_bump rules doing a peek as well?
SNI is not known until/unless after a peek action takes place at step 1.
If your Squid is so old it does not support peek, then it also does not
support SNI.
If you are bumping, or splicing, or terminating at stage 1 of the
ssl-bump process then peek is not happening and the SNI is not
available.
If you are peeking at step1 and the peek is succeeding (not doing a
splice failure recovery) then it is likely a bug.
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
