Yeah I don't know what I am doing wrong but I don't have these ACL types..Or I am somehow not copy & pasting properly: FATAL: Invalid ACL type 'ssl::server_name' FATAL: Bungled /etc/squid/squid.conf line 54: acl nobumpsites ssl::server_name .google.com Squid Cache (Version 3.5.4): Terminated abnormally. CPU Usage: 0.005 seconds = 0.003 user + 0.002 sys Maximum Resident Size: 24096 KB Page faults with physical i/o: 0 Squid restarted [root@ottt-corp-paz-squid-1 squid-3.5.4]# squid -v Squid Cache: Version 3.5.4 Service Name: squid configure options: '--prefix=/usr' '--includedir=/usr/include' '--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid' '--localstatedir=/var' '--sysconfdir=/etc/squid' '--with-included-ltdl' --enable-ltdl-convenience There are also issues with "at_step" now: 2015/05/27 14:32:17| FATAL: Invalid ACL type 'at_step' FATAL: Bungled /etc/squid/squid.conf line 52: acl step1 at_step SslBump1 Squid Cache (Version 3.5.4): Terminated abnormally. CPU Usage: 0.005 seconds = 0.003 user + 0.002 sys Maximum Resident Size: 24080 KB Page faults with physical i/o: 0 Did I miss something when compiling? I just followed what was on the Squid wiki. I am all out of ideas.. Thanks, Mike ----- Original Message ----- From: "Amos Jeffries" <squid3@xxxxxxxxxxxxx> To: "squid-users" <squid-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Wednesday, May 27, 2015 1:20:33 PM Subject: Re: Squid, Gmail.com and HSTS. On 28/05/2015 4:15 a.m., Michael Monette wrote: > Has anyone been able to configure Squid in a way so that if you type https://gmail.com in your browser, you are NOT presented with the "OMG HSTS I refuse to load anything" page? When I go to https://gmail.com, I get an invalid certificate because the cert is for mail.google.com, issued by my CA. If I go to https://mail.google.com, the cert is beautifully green. Why can't squid detect that gmail.com is redirecting my browser to mail.google.com and generate the cert accordingly? That is *actually* what their server certificate contains. Ironic isn't it that their own certs do not comply with the restrictions they require of all others. Squid actually does obey HSTS requirements for secure handling of the reqeust. Its just the browser is incapable of detecting that, notices the custom CA and assumes the worst. > > Even configuring an acl for gmail.com doesn't work. It seems like > even though I am punching https://gmail.com in my browser, Squid detects it as though I am typing "https://mail.google.com"; in my browser and is ignoring any ACLs I have setup specifically for "gmail.com". > > I can't be the only one with this issue? > > > I've also attempted to do: > > acl bl1 gmail.com moz.com > always_direct allow bl1 <- from what I understand this bypasses squid and tells my browser to get the cert right from the site. Maybe I am wrong. > You are. squid.conf has nothing to do with your browser. That line tells Squid not to use any cache_peer connections when serving a request that matches ACL "bl1". In the very first implementation way, way back in 3.1 decrypted requests could leak out over insecure cache_peer. So people were advised to use "always_direct allow all" to force it to work correctly. That bug was fixed long ago but the config still persists in the web. > But certificates still come from Squid, so I don't see any effect from that line. > > Here's my config, lots of garbage in there since I have been trying everything i can think of to get this working. I want to add that for my acl called BL1, the only one that works is moz.com . They are part of the same ACL line, so if one works, they should all work. Except they do not. > > Thanks in advance. > > cat /etc/squid/squid.conf > > ~~ > > debug_options ALL,9 > > acl localnet src 10.0.0.0/8 # RFC1918 possible internal network > acl localnet src 172.16.0.0/12 # RFC1918 possible internal network > acl localnet src 192.168.0.0/16 # RFC1918 possible internal network > acl localnet src fc00::/7 # RFC 4193 local private network range > acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines > > acl SSL_ports port 443 > acl Safe_ports port 80 # http > acl Safe_ports port 21 # ftp > acl Safe_ports port 443 # https > acl Safe_ports port 70 # gopher > acl Safe_ports port 210 # wais > acl Safe_ports port 1025-65535 # unregistered ports > acl Safe_ports port 280 # http-mgmt > acl Safe_ports port 488 # gss-http > acl Safe_ports port 591 # filemaker > acl Safe_ports port 777 # multiling http > acl CONNECT method CONNECT > > > http_access deny !Safe_ports > > http_access deny CONNECT !SSL_ports > > http_access allow localhost manager > http_access deny manager > > acl step1 at_step SslBump1 > acl step2 at_step SslBump2 > acl step3 at_step SslBump3 > > ssl_bump peek step1 all > ssl_bump bump step2 all > ssl_bump bump step3 all "all" at the end of ACL lines has no meaning unless there is an authentication ACL that would otherwise be on the end and you dont want to trigger auth popups. > > acl bl1 dstdomain gmail.com mail.google.com accounts.google.com moz.com > #acl bl1 url_regex -i ^http(s)?://gmail.com > #acl bl2 url_regex -i ^http(s)?://([a-zA-Z]+).gmail.com.* > #acl bl3 url_regex -i ^http(s)?://moz.com.* > #acl bl4 url_regex -i moz.com > deny_info http://ask.com bl1 # I was testing redirecting stuff, but since the acl is not even picked up, this stuff is useless. > http_reply_access deny bl1 # useless Yes, why bother testing for request *URL* domain and blocking on the *reply*. > #http_access deny bl1 > #http_access deny bl1 CONNECT > > http_access allow localnet > http_access allow localhost > > http_access allow all > > http_port 3128 accel vhost allow-direct > > #https_port 3129 transparent ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem options=NO_SSLv3 > https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem options=NO_SSLv3 > > sslproxy_cert_error allow all > sslproxy_flags DONT_VERIFY_PEER > > sslproxy_options NO_SSLv2 > sslproxy_options NO_SSLv3 NOTE: Only the latest sslproxy_options line has any effect. So the NO_SSLv2 line is not obeyed. Use this instead: sslproxy_options NO_SSLv2,NO_SSLv3 Although that said. SSLv2 support was dropped earlier so the latest releases will Anyhow, back to your ACL problem. Be aware that the SNI and cert fields are not the HTTP request URL. * Ensure you are using the latest Squid, today that is a 3.5.4 snapshot (and in ~48hrs will be 3.5.5). * Use the "ssl::server_name" ACL type if you need to block using SNI or server certificate SubjectName. What Squid does for intercepted port 443 traffic is generate a fake CONNECT request using the *IP:port* of the server from TCP. http_access is checked for that. You can block if ou wish or pass it through, ssl_bump may decide not to bump and it can safely be passed through peers, or acted on directly to tunnel the intercepted bytes to the server. If you do SSL-bump with peeking at client and/or server cert the ssl_server_name ACL matches the data found there about the server name/alias. After the decryption SSL-bump process has been completed will you start to get the HTTP requests that were encrypted as HTTPS. The https_access etc are all run normally on those since they are just regular HTTP traffic but for https:// URLs. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
