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@xxxxxxxxxxxxx> 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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
