[squid-users] url_rewrite_program shows IP addresses instead of domain name when rewriting SSL/HTTPS

[Moataz Elmasry]

Hi Amos,

Do you know any of those 'exceptional' redirectors that can handle https?

Ok. So let's ignore the redirection for now and just try to whitelist some
https urls and deny anything else.

Now I'm trying to peek and bump the connection, just to obtain the
servername without causing much harm, but the https sites are now either
loading infinitely, or loading successfully, where they should have been
blacklisted, assuming the https unwrapping happened successfully. Could you
please have a look and tell me what's wrong with the following
configuration? BTW after playing with ssl_bump I realized that I didn't
really understand the steps(1,2,3) as well as when to peek/bump/stare
etc... . The squid.conf contains some comments and questions

squid.conf

"
acl http_sites dstdomain play.google.com mydomain.com
acl https_sites ssl::server_name play.google.com mydomain.com

#match any url where the servername in the SNI is not empty
acl haveServerName ssl::server_name_regex .


http_access allow http_sites
http_access allow https_sites #My expectation is that this rule is matched
when the https connection has been unwrapped

sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

http_access deny all

http_port 3127
http_port 3128 intercept
https_port 3129 cert=/etc/squid/ssl/example.com.cert
key=/etc/squid/ssl/example.com.private ssl-bump intercept
generate-host-certificates=on  version=1
options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE capath=/etc/ssl/certs/

sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3


ssl_bump peek step1  #Is this equivelant to "ssl_bump peek step1 all ???"

ssl_bump bump haveServerName !https_sites
#What about connections that didn't provide sni yet? Do they get to have
own definition for step2?
#Is this equivelant to "ssl_bump  bump step2 haveServerName !https_sites" ??
#Can I use step2 with some other acl?

ssl_bump splice all
#Is this now step3 for all?what about those urls who didn't have a match in
step2. Is this step2 for some and step3 for others?

coredump_dir /var/cache/squid
"

Cheers and many thanks
Moataz

On Fri, Jul 8, 2016 at 12:52 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 8/07/2016 10:42 a.m., Moataz Elmasry wrote:
> > Hi all,
> >
> > I just had an idea. Refering to the last email.
> > The reason why I'm getting those "Header forgery" errors might be because
> > of the defined nat rules. I'm using the following rules:
> >
> > iptables -t nat -A OUTPUT --match owner --uid-owner proxy -p tcp --dport
> 80
> > -j ACCEPT
> > iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination
> > ${MY_IP}:3128
> > iptables -t nat -A OUTPUT --match owner --uid-owner proxy -p tcp --dport
> > 443 -j ACCEPT
> > iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination
> > ${MY_IP}:3129
> >
> > so, the next thing is I changed the --to-destination lines as follows:
> >
> > iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner proxy --dport 443
> > -j REDIRECT --to-port 3129
> >
> > But no success. Do these nat rules have anything to do with the header
> > forgery problem?
>
> Indirectly they do. The existence of NAT is why the security test is
> being done. But that is unlikely to be avoidable.
>
> Amos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160708/14dc018f/attachment.html>