[squid-users] FATAL: Unable to open HTTPS Socket

[Amos Jeffries]

On 26/08/2015 6:51 a.m., Oliver Webb wrote:
> TLDR Skip to ----------
> 
> I have squid 3.5.7 installed on linux with the following configure options:
> 
>  '--build=arm-linux-gnueabihf' '--prefix=/usr' '--localstatedir=/var' '--libexecdir=/usr/lib/squid' '--srcdir=.' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-default-user=proxy' '--with-logdir=/var/log' '--with-pidfile=/var/run/squid.pid' '--enable-ssl' '--with-openssl' '--enable-ssl-crtd' '--enable-delay-pools' '--enable-external-acl-helpers=session' 'build_alias=arm-linux-gnueabihf'
> 
> I have the following ports assigned in squid.conf:
> 
> http_port 3129
> http_port 3128 intercept
> https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/myCA.pem
> 
> I also have IPTables redirecting port 443 traffic to port 3130 and port 80 traffic to 3128
> 
> For port 80 HTTP traffic the proxy works fine pages load except blocked ones which the proxy successfully replaces which blocked message
> 
> Port 443 HTTPS traffic is successfully bumped by squid and the certificate is replaced with the dynamically generated one.
> ----------
> HOWEVER
> The page squid serves over the browser-squid tunnel is the ERR_DNS_FAIL error page with the %H hostname template code evaluated to 'http' (without quotes)
> 

That means one or more of these is most likely:

A) the SNI value sent by the client was "http".
 - that is invalid TLS protocol

B) the Host header in the HTTP message was "Host: http:443" or "Host:
http://blah"
 - both are invalid FQDN

C) the reverse-DNS for the IP address Squid is dealing with says "http"
 - that is an invalid DNS record


Maybe be more I've overlooked right now.


> Also in the cache.log the following message appears after every HTTPS request
> FATAL: Unable to open HTTPS Socket


For (B) and some of (A), try adding "debug_options 11,2 83,5" to your
config file and see what the messages are doing in Squid.
 If there are no HTTP messages, then the issue is in the TLS or DNS layers.

For the rest of (A), you will likely need to use packet captures to see
what is happening on the connections both in and out of Squid
(from-client and to-server). The TLS/SSL library command line test tools
may also be useful there to track the TLS protocol details Squis is not
showing well yet.


For (C) try resolving the domain name "http" from the command line of
your Squid machine.

If you configured dns_nameservers directive in squid.conf repeat that
test using each of the listed servers.

If the machine normal lookup works but the Squid NS fail, you may need
to add dns_defnames and dns_appenddomain directives to your squid.conf
with details that match what /etc/resolv.conf tells the machine to do.


PS. The best setup IMHO, is to remove the dns_* directives entirely and
let Squid use the normal /etc/resolv.conf settings.


Amos