[squid-users] Squid and SSL Bump
squid3 at treenet.co.nz
Wed Jan 10 13:47:55 UTC 2018
On 10/01/18 10:56, Yoinier Hernandez Nieves wrote:
> I answer interline.
>> El 9/01/2018, a las 4:27 p.m., Antony Stone escribió:
>> On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:
>>> I try configure squid 3.5 on CentOS 7 with sslBump.
>>> But I have some problems, the first:
>>> Some HTTPs sites can access, because squid say what I am are not
>>> authenticated. And other sites, yes I can access.
>> Please give us information:
>> 1. An example of sites can you access.
> not https
>> 2. An example of sites can you not access.
>> 3. For problems, show us error messages - quote us what the remote
>> sites tell
> Se encontró el siguiente error al intentar recuperar la dirección URL:
> *Acceso Denegado a la Caché*
> Lo lamento, tu no estás autorizado a solicitar https://outlook.co.il/ de
> este caché hasta que te hayas autenticado.
> Please contact the cache administrator
> if you have difficulties authenticating yourself.
>> 4. Please rephrase "squid say what I am are not authenticated" - this
>> is not
>> clear - what do you mean?
>>> I am authenticated.
>> To what? Squid, or the remote site?
> Squid, see message in Spanish for point 3.
Your Squid log snippets you presented below say that the client which
delivered a CONNECT message to Squid was authenticated. Things inside
the tunnel encryption *cannot* be authenticated as separate things.
Squid associates the credentials from the CONNECT tunnel for each
request inside that tunnel.
That means that if you have any auth related config settings to the
https:// request(s) which cause those credentials to need to be
re-checked, to timeout, or any of a multitude of other situations that
normally occur with auth - then the bumped traffic in that bump'd tunnel
from that point onward cannot be serviced and you will start to have
errors. The only viable solution is to avoid authentication checks on
the decrypted / MITM'd / SSL-Bump'd traffic.
> Other error is that
> Error negotiating SSL on FD 16: error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
> The following error was encountered while trying to retrieve the URL:
> *Failed to establish a secure connection to 188.8.131.52*
> The system returned:
> (71) Protocol error (TLS code: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)
> SSL Certficate error: certificate issuer (CA) not known:
> This proxy and the remote host failed to negotiate a mutually acceptable
> security settings for handling your request. It is possible that the
> remote host does not support secure connections, or the proxy is not
> satisfied with the host security credentials.
Please read the above error message carefully. It explains exactly what
is going wrong, and from that you should be able to find the MANY
discussion threads that exact same error message has had in here and
elsewhere over the past few years.
Your options are to:
(may require a Squid-3.5 upgrade), or
* upgrade to Squid-4 which auto-downloads these things.
>> How do you know you are authenticated - what confirmation do you have?
>>> Fragment of my squid.conf.
>>> http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
>>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
>>> options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
>>> /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
>>> acl step1 at_step SslBump1
>>> acl step2 at_step SslBump2
>>> acl step3 at_step SslBump3
>>> ssl_bump peek step1
>>> ssl_bump bump all
>>> authenticate_ip_ttl 60 seconds
>> That looks a bit strange (and a bit incomplete) to me, but since I'm
>> no expert
>> on SSL interception, I'll let someone else step in here.
The authenticate_ip_ttl is irrelevant except that if the auth system
obeys it, the result will be all persistent connections producing errors
60 seconds after they become authenticated.
>> If you can provide more information in the meantime (eg: enough to help
>> someone else replicate your problem) that would be good.
> I use too dansguardians before the squid proxy.
> See the logs for one petition
> 1515534858.355 3720 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT
> www.ssllabs.com:443 <http://www.ssllabs.com:443> ynieves
> HIER_DIRECT/184.108.40.206 -
> 1515534858.375 0 bbb.bbb.bbb.bbb TCP_DENIED/403 4457 GET
> https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/-
> 1515534858.407 0 bbb.bbb.bbb.bbb TAG_NONE/503 4952 GET
> ynieves HIER_DIRECT/220.127.116.11 text/html
> aaa.aaa.aaa.aaa is my pc.
> bbb.bbb.bbb.bbb is the dansguardians
This is Squid delivering that above TLS error message to the
client.Because of how browsers refuse to display errors presented by
proxies to CONNECT requests. Squid is being forced to decrypt the HTTP
message in the HTTPS tunnel and send the error page as a response to
that encrypted request.
More information about the squid-users