[squid-users] Squid and SSL Bump

Amos Jeffries 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.
> https://www.ssllabs.com/ssltest/viewMyClient.html
> https://outlook.co.il/
> https://www.facebook.com
> 
>> 3. For problems, show us error messages - quote us what the remote 
>> sites tell
>> you.
> 
> Se encontró el siguiente error al intentar recuperar la dirección URL: 
> https://outlook.co.il/
> 
>     *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 
> <mailto:root?subject=CacheErrorInfo%20-%20ERR_CACHE_ACCESS_DENIED&body=CacheHost%3A%20artemisa.conalza.co.cu%0D%0AErrPage%3A%20ERR_CACHE_ACCESS_DENIED%0D%0AErr%3A%20%5Bnone%5D%0D%0ATimeStamp%3A%20Tue,%2009%20Jan%202018%2019%3A12%3A22%20GMT%0D%0A%0D%0AClientIP%3A%20172.25.100.4%0D%0A%0D%0AHTTP%20Request%3A%0D%0AGET%20%2F%20HTTP%2F1.1%0AUser-Agent%3A%20Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010.12%3B%20rv%3A57.0)%20Gecko%2F20100101%20Firefox%2F57.0%0D%0AAccept%3A%20text%2Fhtml,application%2Fxhtml+xml,application%2Fxml%3Bq%3D0.9,*%2F*%3Bq%3D0.8%0D%0AAccept-Language%3A%20es-ES,es%3Bq%3D0.8,en-US%3Bq%3D0.5,en%3Bq%3D0.3%0D%0AAccept-Encoding%3A%20gzip,%20deflate,%20br%0D%0AConnection%3A%20keep-alive%0D%0AUpgrade-Insecure-Requests%3A%201%0D%0AHost%3A%20outlook.co.il%0D%0A%0D%0A%0D%0A> 
> 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
> https://www.kiosco.bandec.cu/kiosco
> 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: 
> https://www.kiosco.bandec.cu/*
> 
>     *Failed to establish a secure connection to 190.6.64.132*
> 
> 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:
>     /CN=CX6.bandec.cu
> 
> 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:

* configure 
<http://www.squid-cache.org/Doc/config/sslproxy_foreign_intermediate_certs/> 
(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
>>> NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
>>> 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/64.41.200.100 -
> 1515534858.375      0 bbb.bbb.bbb.bbb TCP_DENIED/403 4457 GET 
> https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- 
> text/html
> 1515534858.407      0 bbb.bbb.bbb.bbb TAG_NONE/503 4952 GET 
> http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png 
> ynieves HIER_DIRECT/64.41.200.100 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.



Amos


More information about the squid-users mailing list