<div dir="ltr">Sorry, I just realized, I sent you a private email instead of to the mailing list. Apologies for that. <div><br></div><div><span style="font-size:12.8px">Hi Amos,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I did some progress today so that least I'm not getting any errors in the browser, te url_redirect_program receives the actual url. Redirecting normal http urls work fine, but redirecting https urls results in a similar error in the logs:</div><div style="font-size:12.8px">"</div><div style="font-size:12.8px"><div>2016/07/07 17:19:28| SECURITY ALERT: Host header forgery detected on local=<a href="http://31.13.92.36:443/" target="_blank">31.13.92.36:443</a> remote=x.x.x.x:65228 FD 18 flags=33 (local IP does not match any domain IP)</div><div>2016/07/07 17:19:28| SECURITY ALERT: on URL: <a href="http://www.facebook.com:443/" target="_blank">www.facebook.com:443</a></div></div><div style="font-size:12.8px">"</div><div style="font-size:12.8px">And the browser tab hags (in page loading)</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Heres the <span class="">squid</span>.conf important parts</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">"</div><div style="font-size:12.8px"><div>acl http_sites dstdomain <a href="http://play.google.com/" target="_blank">play.google.com</a> <a href="http://mydomain.com/" target="_blank">mydomain.com</a></div><span class="im"><div>acl https_sites ssl::server_name <a href="http://play.google.com/" target="_blank">play.google.com</a> <a href="http://mydomain.com/" target="_blank">mydomain.com</a></div><div><br></div><div>acl HTTP proto HTTP</div><div>acl HTTPS proto HTTPS</div><div><br></div></span><div>http_access allow http_sites</div><div>http_access allow https_sites</div><span class="im"><div><br></div><div>sslcrtd_program /lib/<span class="">squid</span>/ssl_crtd -s /var/lib/ssl_db -M 4MB</div><div><br></div><div>http_access allow all</div><div><br></div></span><span class="im"><div>http_port 3127</div><div>http_port 3128 intercept</div></span><div>https_port 3129 cert=/etc/<span class="">squid</span>/ssl/example.com.cert key=/etc/<span class="">squid</span>/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><span class="im"><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></span><div>ssl_bump peek step1 all</div><div>ssl_bump splice step2 all !https_sites </div><div>ssl_bump bump step3 all !https_sites</div><span class="im"><div><br></div><div><br></div><div>url_rewrite_program /bin/bash -c -l /etc/<span class="">squid</span>/redirect.bash</div></span><div>url_rewrite_extras "%>a/%>A %<A %un %>rm myip=%la myport=%lp ru=%ru ru2=%>ru ru3=%<ru rd=%>rd rd2=%<rd h=%>h ssl1=%ssl::bump_mode ssl2=%ssl::>sni rp1=%rp rp2=%>rp rp3=%<rp h1=%>h h2=%>ha"</div><div>logformat <span class="">squid</span> "%>a/%>A %<A %un %>rm myip=%la myport=%lp ru=%ru ru2=%>ru ru3=%<ru rd=%>rd rd2=%<rd h=%>h ssl1=%ssl::bump_mode ssl2=%ssl::>sni rp1=%rp rp2=%>rp rp3=%<rp h1=%>h h2=%>ha"</div><div>url_rewrite_access allow all !http_sites !https_sites</div><div><br></div><div># Leave coredumps in the first cache dir</div><div>coredump_dir /var/cache/<span class="">squid</span></div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">"</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I searched a bit on the "Host header forgery detected" but could not find a similar situation to mines</div><div style="font-size:12.8px">Any ideas how to overcome this error?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Many thanks and regards,</div><div style="font-size:12.8px">Moataz</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 9:30 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 2016-07-06 10:48, Moataz Elmasry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I'm trying to create a kind of captive portal when only my domain and<br>
google play are whitelisted and other addresses(http/https) are<br>
forwarded to my domain.<br>
All http requests are landing fine in the url_rewrite program, while<br>
the https requests appear as only the IP address but not the dns name.<br>
I'm aware of <a href="http://wiki.squid-cache.org/Features/SslPeekAndSplice" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/Features/SslPeekAndSplice</a> and<br>
especially the note that during ssl_bump no dns name is available yet<br>
and instead one should be using the acl ssl::server_name directive,<br>
but for some reason no https address is being sent to my url_rewrite<br>
program.<br>
<br>
The same SSL certificate used on my domain is also being used with<br>
squid at https_port<br>
</blockquote>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><span class="">
Here's my squid.conf<br>
<br>
"<br>
<br>
pinger_enable off<br></span>
acl localnet src <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a> [1] # RFC1918 possible internal network<br>
<br>
acl localnet src <a href="http://172.16.0.0/12" rel="noreferrer" target="_blank">172.16.0.0/12</a> [2] # RFC1918 possible internal network<br>
acl localnet src <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> [3] # RFC1918 possible internal<span class=""><br>
network<br>
<br>
acl SSL_ports port 443<br>
acl Safe_ports port 80 # http<br>
acl Safe_ports port 443 # https<br>
acl Safe_ports port 1025-65535 # unregistered ports<br>
acl CONNECT method CONNECT<br>
<br>
http_access deny !Safe_ports<br>
http_access deny CONNECT !SSL_ports<br>
<br>
http_access allow localhost manager<br>
http_access deny manager<br>
http_access allow localnet<br>
<br>
http_access allow localhost<br>
<br></span>
acl http dstdomain <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> [4] <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a> [5]<br>
acl https ssl::server_name <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> [4] <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a> [5]<br>
</blockquote>
<br>
This is ... weird. There is nothing in the ACL matching which would indicate it was HTTP vs HTTPS.<br>
<br>
* dstdomain can match for CONNECT tunnels transferring non-HTTP traffic when the URI contains the domain specified. It only indicates that HTTP was used by the client ... except for intercepted HTTPS traffic, where it merely indicates that Squid itself is wrapping the inbound traffic into HTTP compatible format before interpreting them. Squid sometimes uses the TLS SNI value as the URI dstdomain.<br>
-> unreliable.<br>
<br>
* TLS SNI can contain the listed server name for non-HTTPS protocols.<br>
-> unreliable.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
http_access allow http<br>
http_access allow https<br>
</blockquote>
<br></span>
* "http_access" means Squid is testing whether an HTTP protocol client is allowed to use the proxy. The "http" URL contains HTTP protocol matching. Which is okay, but see above about what the "dstdomain "value could be.<br>
<br>
* The "https" ACL contains TLS details matching - so is usually not possible to even test like this.<br>
<br>
* localnet and localhost are already allowed to do anything safe by the earlier http_access rules. I doubt these confused matches are even getting used.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
url_rewrite_program /bin/bash -c -l /etc/squid/redirect.bash<br>
<br>
url_rewrite_access allow all !http<br>
url_rewrite_access allow all !https<br>
</blockquote>
<br></span>
Several problems here:<br>
<br>
* "all" is only a meaningless waste of CPU time and memory in this usage.<br>
<br>
* "https" ACL probably is not possible to match. Rewriting of the *HTTP* URL is a HTTP decision. Not TLS.<br>
<br>
* The use of negation (!) means you have expicitly configured Squid *not* to send any lookups to the helper when the ACL listed domain name(s) are present in the HTTP request.<br>
So you were asking why no requests with the domain name show up in the helper?<br>
Squid is obeying your explicit instructions not to send them.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB<br>
<br>
http_access allow all<br>
</blockquote>
<br></span>
Not safe.<br>
<br>
localnet and localhost are already allowed to do anything safe by the earlier http_access rules. SO you should not see a change if you set this back to the "deny all" which it should be.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
http_port 3127<br>
http_port 3128 intercept<br>
</blockquote>
<br></span>
Not safe practice. Port 3128 is the officialy registered Squid proxy port and quite well known. There are several attacks that can be done if the attacker happens to identify what intercept port is numbered and connect there. Use a randomly selected other port number.<br>
<br>
Same for the below 3129. It is used in our documetation as an example only.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
https_port 3129 intercept cert=mycert.cert key=mykey.key ssl-bump<br>
intercept generate-host-certificates=on version=1<br>
options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE cafile=Intermediate.crt<br>
<br>
always_direct allow all<br>
</blockquote>
<br></span>
always_direct is not needed for SSL-Bump. It was a bug workaround needed only for a very few releases many years ago now.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
acl step1 at_step SslBump1<br>
acl step2 at_step SslBump2<br>
acl step3 at_step SslBump3<br>
<br>
ssl_bump splice localhost<br>
ssl_bump splice https<br>
<br>
</blockquote>
<br></span>
You are splicing traffic. This means there are no HTTPS messages interpreted by Squid. Thus no possibility of your URL-rewrite helper ever being even considered for use on them.<br>
At best it might be considered for the CONNECT tunnel used by splice, but that means CONNECT URI has its domain set, the dstdomain would match and "!http" comes into affect to prevent it being asked.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ssl_bump peek step1<br>
ssl_bump peek all<br>
<br>
coredump_dir /var/cache/squid<br>
"<br>
<br>
So any idea why no https urls are being redirected to the url_rewrite<br>
program?<br>
Any alternative solution is also very much welcome<br>
<br>
</blockquote>
<br></span>
1) If you really meant to detect HTTP vs HTTPS traffic. Use the proper ACL definitions:<br>
acl HTTP proto HTTP<br>
acl HTTPS proto HTTPS<br>
<br>
<br>
2) Most rewriters cannot correctly handle the URI type used on CONNECT tunnels, and more importantly are not able to safely decide where to redirect to even if they could produce the right URI output.<br>
<br>
So, normal installations should block requests to your re-writer by using the available "CONNECT" ACL like so:<br>
url_rewrite_access deny CONNECT<br>
<br>
However, if your rewriter is an exception and can actually divert whole tunnels correctly (or knows corectly to return "ERR" and skip re-writing). Then use the method field it receives from Squid to have it decide what to do.<br>
<br>
3) If you want to rewrite or redirect https:// URLs ... in other words modifying the HTTPS messages inside the crypto.<br>
<br>
That requires "ssl_bump bump" action to be configured and the traffic decrypted.<br>
<br>
<br>
HTH<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div>