Sorry, I just realized, I sent you a private email instead of to the mailing list. Apologies for that.
Hi Amos, 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: " 2016/07/07 17:19:28| SECURITY ALERT: Host header forgery detected on local= 31.13.92.36:443 remote=x.x.x.x:65228 FD 18 flags=33 (local IP does not match any domain IP) 2016/07/07 17:19:28| SECURITY ALERT: on URL: www.facebook.com:443 " And the browser tab hags (in page loading) Heres the squid.conf important parts " acl http_sites dstdomain play.google.com mydomain.com acl https_sites ssl::server_name play.google.com mydomain.com acl HTTP proto HTTP acl HTTPS proto HTTPS http_access allow http_sites http_access allow https_sites sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB http_access allow 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 all ssl_bump splice step2 all !https_sites ssl_bump bump step3 all !https_sites url_rewrite_program /bin/bash -c -l /etc/squid/redirect.bash 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" logformat squid "%>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" url_rewrite_access allow all !http_sites !https_sites # Leave coredumps in the first cache dir coredump_dir /var/cache/squid " I searched a bit on the "Host header forgery detected" but could not find a similar situation to mines Any ideas how to overcome this error? Many thanks and regards, Moataz On Wed, Jul 6, 2016 at 9:30 AM, Amos Jeffries <squ...@treenet.co.nz> wrote: > On 2016-07-06 10:48, Moataz Elmasry wrote: > >> Hi all, >> >> I'm trying to create a kind of captive portal when only my domain and >> google play are whitelisted and other addresses(http/https) are >> forwarded to my domain. >> All http requests are landing fine in the url_rewrite program, while >> the https requests appear as only the IP address but not the dns name. >> I'm aware of http://wiki.squid-cache.org/Features/SslPeekAndSplice and >> especially the note that during ssl_bump no dns name is available yet >> and instead one should be using the acl ssl::server_name directive, >> but for some reason no https address is being sent to my url_rewrite >> program. >> >> The same SSL certificate used on my domain is also being used with >> squid at https_port >> > > >> Here's my squid.conf >> >> " >> >> pinger_enable off >> acl localnet src 10.0.0.0/8 [1] # RFC1918 possible internal network >> >> acl localnet src 172.16.0.0/12 [2] # RFC1918 possible internal network >> acl localnet src 192.168.0.0/16 [3] # RFC1918 possible internal >> network >> >> acl SSL_ports port 443 >> acl Safe_ports port 80 # http >> acl Safe_ports port 443 # https >> acl Safe_ports port 1025-65535 # unregistered ports >> acl CONNECT method CONNECT >> >> http_access deny !Safe_ports >> http_access deny CONNECT !SSL_ports >> >> http_access allow localhost manager >> http_access deny manager >> http_access allow localnet >> >> http_access allow localhost >> >> acl http dstdomain play.google.com [4] mydomain.com [5] >> acl https ssl::server_name play.google.com [4] mydomain.com [5] >> > > This is ... weird. There is nothing in the ACL matching which would > indicate it was HTTP vs HTTPS. > > * 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. > -> unreliable. > > * TLS SNI can contain the listed server name for non-HTTPS protocols. > -> unreliable. > > >> http_access allow http >> http_access allow https >> > > * "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. > > * The "https" ACL contains TLS details matching - so is usually not > possible to even test like this. > > * 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. > > >> url_rewrite_program /bin/bash -c -l /etc/squid/redirect.bash >> >> url_rewrite_access allow all !http >> url_rewrite_access allow all !https >> > > Several problems here: > > * "all" is only a meaningless waste of CPU time and memory in this usage. > > * "https" ACL probably is not possible to match. Rewriting of the *HTTP* > URL is a HTTP decision. Not TLS. > > * 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. > So you were asking why no requests with the domain name show up in the > helper? > Squid is obeying your explicit instructions not to send them. > > > >> sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB >> >> http_access allow all >> > > Not safe. > > 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. > > >> http_port 3127 >> http_port 3128 intercept >> > > 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. > > Same for the below 3129. It is used in our documetation as an example only. > > > https_port 3129 intercept cert=mycert.cert key=mykey.key ssl-bump >> intercept generate-host-certificates=on version=1 >> options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE cafile=Intermediate.crt >> >> always_direct allow all >> > > always_direct is not needed for SSL-Bump. It was a bug workaround needed > only for a very few releases many years ago now. > > acl step1 at_step SslBump1 >> acl step2 at_step SslBump2 >> acl step3 at_step SslBump3 >> >> ssl_bump splice localhost >> ssl_bump splice https >> >> > 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. > 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. > > > ssl_bump peek step1 >> ssl_bump peek all >> >> coredump_dir /var/cache/squid >> " >> >> So any idea why no https urls are being redirected to the url_rewrite >> program? >> Any alternative solution is also very much welcome >> >> > 1) If you really meant to detect HTTP vs HTTPS traffic. Use the proper ACL > definitions: > acl HTTP proto HTTP > acl HTTPS proto HTTPS > > > 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. > > So, normal installations should block requests to your re-writer by using > the available "CONNECT" ACL like so: > url_rewrite_access deny CONNECT > > 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. > > 3) If you want to rewrite or redirect https:// URLs ... in other words > modifying the HTTPS messages inside the crypto. > > That requires "ssl_bump bump" action to be configured and the traffic > decrypted. > > > HTH > Amos > >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
