[squid-users] Squid 4.6 "SSL routines:tls_parse_stoc_sct:bad extension"

Wed Apr 17 21:32:18 UTC 2019

On 16/04/19 10:34 pm, Christian Schnatz wrote:
> Hi Everyone,
> 
> we’ve just updated one of our machines to squid 4.6 with openssl 1.1.1 and ran in some strange errors when accessing *.google.com and apple app/itunes store domains. 
> Has anyone else encountered the follow errors and nows how to solve them? Right now clients are unable to browse the apple app store and do get a squid error page when accessing google.com.
> 
> Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 202: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback (1/-1/0)

A 5min web search can be useful.

 <https://security.stackexchange.com/questions/160922/ssl-error-inappropriate-fallback-and-tls-fallback-scsv>

> Apr 16 12:17:05 squid[2201]: 1555409825.478    327 172.20.233.28 NONE/200 0 CONNECT 104.31.75.217:443 - ORIGINAL_DST/104.31.75.217 -
> 
> Apr 16 12:17:05 squid[2203]: 1555409825.184  10099 172.20.228.187 NONE_ABORTED/200 0 CONNECT 213.180.141.156:443 - HIER_NONE/- -
> Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 873: error:1423406E:SSL routines:tls_parse_stoc_sct:bad extension (1/-1/0)

Your OpenSSL library does not understand the TLS extension being
received from one endpoint. The client or server, depending on which
step the SSL-Bump process is up to and what your ssl_bump rules say to do.

It is possible that your OpenSSL installation is corrupted, that the
endpoint is using some mandatory avoid TLS/SSL extension that is no
longer supported, that the endpoint is not sending TLS/SSL at all, or a
number of other similar things.

> 
> We are running squid with the following config:
> 
> sslproxy_cert_error allow all
> https_port 3129 ssl-bump intercept connection-auth=off tls-cert=/etc/squid/myCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=12MB options=ALL
> tls_outgoing_options options=ALL

The above options enables (or disables) a lot of OpenSL features which
are set with default on/off for very good reasons. Usually because they
cause bad problems if used on general TLS traffic. Things like 0-bit
security keys, nul-ciphers, IE 3 compatibility ciphers, SSLv2 and so on.

If used at all the "ALL" shoudl be followed by a long list of things to
turn off again. Or prefixed with a '!' to disable everything, followed
by a long list of things to turn on. Just by itself is a bad idea.

> tls_outgoing_options flags=DONT_VERIFY_PEER

This is another even worse idea. It is hiding TLS problems from you.
Serious ones with the security keys and certs.

> tls_outgoing_options default-ca=off
> tls_outgoing_options min-version=1.0

TLS has no version older than 1.0. So the above line is pointless.

> 
> follow_x_forwarded_for allow all
> logfile_rotate 2
> access_log syslog:LOG_LOCAL0:EMERGENCY squid
> max_filedescriptors 65535
> 
> http_port 3131
> 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 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
> http_access allow localnet
> http_access allow localhost
> http_access deny all
> http_port 3128 transparent

"transparent" is a long ago deprecated option. It was replaced by
"intercept" to avoid confusion with transparent proxy options that do
*actual* transparency.

> #debug_options ALL,9
> coredump_dir /var/spool/squid
> url_rewrite_program /usr/bin/cf_plugin
> url_rewrite_extras "%ssl::>sni %>a %et"
> 
> refresh_pattern ^ftp:		1440	20%	10080
> refresh_pattern ^gopher:	1440	0%	1440
> refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
> refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
> refresh_pattern .		0	20%	4320
> 
> cache deny all
> cache_log /dev/null

Another bad idea. This can lead to /dev/null being moved to /dev/null.0
and a file put at /dev/null . Imagine the machine disks over-filling
with infinite amounts of crap from every application and script ever
running.
 Use "debug_options ALL,0" to minimize cache.log output.

> logfile_rotate 0
> 
> sslproxy_session_cache_size 0 MB
> 
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> 
> external_acl_type bump_check children-max=10 %URI %ssl::>sni %>a %et /usr/bin/cf_plugin -b
> acl cf_allows external bump_check
> 
> ssl_bump peek ssl_step1 all
> always_direct allow all

You do not have any cache_peer's.  This always_direct is not useful in
any way. Please remove.

> ssl_bump peek ssl_step2 cf_allows
> ssl_bump bump ssl_step3 all
> ssl_bump stare ssl_step2 !cf_allows
> ssl_bump splice ssl_step3 cf_allows
> ssl_bump bump ssl_step3 !cf_allows

The above lines should never be reachable. There is already a bump rule
that matches step3. If that rule is not possible, then this one cannot
be either.

> 
> Our main usage is to extract the SNI or IP from the SSL Request, forward it to cf_plugin and do some magic to decide wether this request should be blocked or not.
> 

At no point do these ssl_bump rules block anything. In fact they do the
opposite.

They decide whether to allow unconditional tunnel through the proxy
(splice) or whether to decrypt and let the rest of the proxy do things
to the traffic (bump).

The other access rules in your proxy just allow if anything ecrypted
comes from a localnet client. So nothing in the way of blocking based on
SNI, URL domain or such ever happens.

HTH
Amos