[squid-users] Squid 4.6 cannot open 2 other popular domains with SSL bump

Thu Apr 18 10:32:23 UTC 2019

On 18/04/19 9:26 pm, info at schroeffu.ch wrote:
> Hi Squid Users,
> 
> with Squid 4.6 I cannot open these 2 domains when SSL bump is enabled:
> 
> https://www.hays.de
> https://www.plantronics.com
> 
> Both are showing me a different type of error, details below.
> I could not find any HPKP site or subdomain there, so I guess Squid has
> another problem with this domains.
> Can somebody explain me how I should debug that correctly, to open a
> bugreport?
> 
> ### Bump Settings:
> 
> acl domains_dont_sslbump ssl::server_name_regex
> "/etc/squid/ka/domains_dont_sslbump.acl"
> acl domains_dont_sslbump ssl::server_name_regex
> "/etc/squid/blacklists/blacklist_ut1/blacklists/bank/domains"
> acl domains_dont_sslbump ssl::server_name_regex
> "/etc/squid/blacklists/blacklist_shallalist/BL/finance/banking/domains"
> acl domains_dont_sslbump ssl::server_name_regex
> "/etc/squid/blacklists/blacklist_shallalist/BL/finance/other/domains"
> 
> http_port proxy02:8080 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/cert.pem
> key=/etc/squid/certs/key.ohnersa.pem
> sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db
> -M 4MB
> always_direct allow all

You are no longer using an experimental patch on Squid-3.2. If you ever
did. This config hack to work around a very short lived / temporary bug
in SSL-Bump behaviour has not been necessary for many years.

> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all !domains_dont_sslbump
> 
> #### hays.de:
> 1555577795.968 1 172.16.x.x TCP_DENIED/407 4995 GET http://hays.de/ -
> HIER_NONE/- text/html
> 1555577796.067 63 172.16.x.x TCP_MISS/301 465 GET http://hays.de/ user1
> HIER_DIRECT/149.126.72.70 -
> 1555577796.083 0 172.16.x.x TCP_DENIED/407 4124 CONNECT hays.de:443 -
> HIER_NONE/- text/html
> 1555577796.101 1 172.16.x.x TCP_DENIED/407 4460 CONNECT hays.de:443 -
> HIER_NONE/- text/html
> 1555577796.202 86 172.16.x.x NONE/200 0 CONNECT hays.de:443 user1
> HIER_DIRECT/149.126.72.70 -
> 1555577796.302 15 172.16.x.x TCP_MISS/301 345 GET https://hays.de/ user1
> HIER_DIRECT/149.126.72.70 -
> 1555577796.320 0 172.16.x.x TCP_DENIED/407 4140 CONNECT www.hays.de:443
> - HIER_NONE/- text/html
> 1555577796.333 1 172.16.x.x TCP_DENIED/407 4476 CONNECT www.hays.de:443
> - HIER_NONE/- text/html
> 1555577796.507 158 172.16.x.x NONE/200 0 CONNECT www.hays.de:443 user1
> HIER_DIRECT/149.126.77.70 -
> 1555577796.602 30 172.16.x.x TCP_MISS_ABORTED/000 0 GET
> https://www.hays.de/ user1 HIER_DIRECT/149.126.77.70 -
> 
> Error displayed on https://www.hays.de (from the Browser Chrome/or Firefox):
> 
> Chrome: ERR_EMPTY_RESPONSE
> Firefox: Secure Connection Failed // An error occurred during a
> connection to www.hays.de. // The page you are trying to view cannot be
> shown because the authenticity of the received data could not be
> verified. // Please contact the website owners to inform them of this
> problem.
> 
> Header Response while this error message is displayed:
> 
> HTTP/1.1 200 Connection established
> Server: squid
> Mime-Version: 1.0
> Date: Thu, 18 Apr 2019 09:05:28 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 3759
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: NTLM VNTUAACAAAADAAMAD(...)
> X-Cache: MISS from proxy02
> X-Cache-Lookup: NONE from proxy02:8080
> Via: 1.1 proxy02 (squid)
> Connection: keep-alive

This is the plain-text message in response to the client CONNECT
request. All it does is tell the Browser that the proxy has given is a
TCP connection (er tunnel) to the origin and it can start the TLS
handshakes.

The 'empty response' Chrome is mentioning is what follows the TLS
handshake, which itself follows the above plain-text headers. If the TLS
fails for any reason there will be no such response.
 So this is Chrome willfully hiding TLS errors from the user while
taking the opportunity to blame the proxy for those failures it has
exchanging TLS with the _origin_ server.

Note that all out SSL-Bump related documentation states that "when used
properly TLS cannot be bumped". Specifically the X.509 server
certificate cannot be forced to be trusted by the clients. If they are
aware (via a number of other means) what that certificate should look
like they *will* reject Squids generated (forged) server cert.
 Good luck finding out whether that is the case though. Browser people
like to hide such details from us all.
 Try to perform these HTTPS transactions without using a Browser. That
should make it clearer what the issue is, and in which piece of software
(Browser, Squid, OpenSSL, or origin server).

The other common alternative is that these sites TLS is suddenly broken.
Test if traffic works without the proxy. Preferably with a tool that can
show you the TLS handshake particulars.

> 
> #### plantronics.com
> 1555577912.476 391 172.16.x.x TCP_MISS/301 869 GET
> http://plantronics.com/ user1 HIER_DIRECT/198.231.10.19 text/html
> 1555577912.514 0 172.16.x.x TCP_DENIED/407 4172 CONNECT
> www.plantronics.com:443 - HIER_NONE/- text/html
> 1555577912.529 1 172.16.x.x TCP_DENIED/407 4508 CONNECT
> www.plantronics.com:443 - HIER_NONE/- text/html
> 1555577912.864 324 172.16.x.x NONE/200 0 CONNECT www.plantronics.com:443
> user1 HIER_DIRECT/54.192.94.216 -
> 1555577913.564 521 172.16.x.x TCP_MISS/403 745 GET
> https://www.plantronics.com/ user1 HIER_DIRECT/54.192.94.216 text/html
> 
> Error displayed on frontpage https://www.plantronics.com (from their
> Apache or Nginx):
> 
> Forbidden
> You don't have permission to access /.noindex.html on this server.
> 

Notice that this is a page generated by *their* server. Your proxy is
successfully decrypting the traffic. Their server is not happy or
understanding the HTTPS requests arriving after that.

Amos