<div dir="ltr">Hi Amos,<div><br></div><div>Do you know any of those 'exceptional' redirectors that can handle https?</div><div><br></div><div>Ok. So let's ignore the redirection for now and just try to whitelist some https urls and deny anything else.</div><div><br></div><div>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</div><div><br></div><div>squid.conf</div><div><br></div><div>"</div><div><div>acl http_sites dstdomain <a href="http://play.google.com">play.google.com</a> <a href="http://mydomain.com">mydomain.com</a></div><div>acl https_sites ssl::server_name <a href="http://play.google.com">play.google.com</a> <a href="http://mydomain.com">mydomain.com</a></div><div><br></div><div>#match any url where the servername in the SNI is not empty</div><div>acl haveServerName ssl::server_name_regex .</div><div><br></div><div><br></div><div>http_access allow http_sites</div><div>http_access allow https_sites #My expectation is that this rule is matched when the https connection has been unwrapped</div><div><br></div><div>sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB</div><div><br></div><div>http_access deny all</div><div><br></div><div>http_port 3127</div><div>http_port 3128 intercept</div><div>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/</div><div><br></div><div>sslproxy_cert_error allow all </div><div>sslproxy_flags DONT_VERIFY_PEER </div><div><br></div><div>acl step1 at_step SslBump1</div><div>acl step2 at_step SslBump2</div><div>acl step3 at_step SslBump3</div><div><br></div><div><br></div><div>ssl_bump peek step1  #Is this equivelant to "ssl_bump peek step1 all ???"</div><div><br></div><div>ssl_bump bump haveServerName !https_sites</div><div>#What about connections that didn't provide sni yet? Do they get to have own definition for step2?<br></div><div>#Is this equivelant to "ssl_bump  bump step2 haveServerName !https_sites" ??</div><div>#Can I use step2 with some other acl?</div><div><br></div><div>ssl_bump splice all</div><div>#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?</div><div><br></div><div>coredump_dir /var/cache/squid</div></div><div>"</div><div><br></div><div>Cheers and many thanks</div><div>Moataz</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 12:52 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/07/2016 10:42 a.m., Moataz Elmasry wrote:<br>
> Hi all,<br>
><br>
</span><span class="">> I just had an idea. Refering to the last email.<br>
> The reason why I'm getting those "Header forgery" errors might be because<br>
> of the defined nat rules. I'm using the following rules:<br>
><br>
> iptables -t nat -A OUTPUT --match owner --uid-owner proxy -p tcp --dport 80<br>
> -j ACCEPT<br>
> iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination<br>
> ${MY_IP}:3128<br>
> iptables -t nat -A OUTPUT --match owner --uid-owner proxy -p tcp --dport<br>
> 443 -j ACCEPT<br>
> iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination<br>
> ${MY_IP}:3129<br>
><br>
> so, the next thing is I changed the --to-destination lines as follows:<br>
><br>
> iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner proxy --dport 443<br>
> -j REDIRECT --to-port 3129<br>
><br>
> But no success. Do these nat rules have anything to do with the header<br>
> forgery problem?<br>
<br>
</span>Indirectly they do. The existence of NAT is why the security test is<br>
being done. But that is unlikely to be avoidable.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div>