Default host_verify_strict behavior appears to have changed as of 3.5.25

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Default host_verify_strict behavior appears to have changed as of 3.5.25

steveno
I was using squid 3.5.20 I encountered an issue running out of File
Descriptors on Centos7, the scebario was that sockets would be abandoned in
a "CLOSE_WAIT" state forever until the server ran out of FD's.
Searching I found the following BUG.
https://bugs.squid-cache.org/show_bug.cgi?id=4508
This is listed as being a fix at 3.5.25, so I installed that version, once
installed the FD problem seemed to be resolved, but now there is another
issue "Default Value: host_verify_strict off" seems to be lost, in my access
logs I get an number of entries:
2018-02-07 17:10:42      0 10.x.x.x TAG_NONE/409 3941 CONNECT
sqs.us-west-2.amazonaws.com:443 sqs.us-west-2.amazonaws.com HIER_NONE/-
text/html

Cache logs I get:
2018/02/07 17:57:45 kid1| SECURITY ALERT: on URL:
sqs.us-west-2.amazonaws.com:443

And the clients making those requests tend to see dropped connections with a
"SSL: UNKNOWN_PROTOCOL" error.

I tried setting the value "host_verify_strict off" but it did not appear to
have any effect.

It looks like this fix for the File Descriptors has broken something else.

Thanks.

Steven Oakley.



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Default host_verify_strict behavior appears to have changed as of 3.5.25

Yuri Voinov
This irrelevant to host_verify_strict. This is effect of server side CDN
IP changes. Squid threats it as security alert.

08.02.2018 00:03, steveno пишет:

> I was using squid 3.5.20 I encountered an issue running out of File
> Descriptors on Centos7, the scebario was that sockets would be abandoned in
> a "CLOSE_WAIT" state forever until the server ran out of FD's.
> Searching I found the following BUG.
> https://bugs.squid-cache.org/show_bug.cgi?id=4508
> This is listed as being a fix at 3.5.25, so I installed that version, once
> installed the FD problem seemed to be resolved, but now there is another
> issue "Default Value: host_verify_strict off" seems to be lost, in my access
> logs I get an number of entries:
> 2018-02-07 17:10:42      0 10.x.x.x TAG_NONE/409 3941 CONNECT
> sqs.us-west-2.amazonaws.com:443 sqs.us-west-2.amazonaws.com HIER_NONE/-
> text/html
>
> Cache logs I get:
> 2018/02/07 17:57:45 kid1| SECURITY ALERT: on URL:
> sqs.us-west-2.amazonaws.com:443
>
> And the clients making those requests tend to see dropped connections with a
> "SSL: UNKNOWN_PROTOCOL" error.
>
> I tried setting the value "host_verify_strict off" but it did not appear to
> have any effect.
>
> It looks like this fix for the File Descriptors has broken something else.
>
> Thanks.
>
> Steven Oakley.
>
>
>
> --
> Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
--
*****************************
* C++20 : Bug to the future *
*****************************



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Default host_verify_strict behavior appears to have changed as of 3.5.25

steveno
OK this may be irrelevant to the "host_verify_strict" setting, its just when
I looked at the messages like "2018/02/07 17:57:45 kid1| SECURITY ALERT: on
URL: sqs.us-west-2.amazonaws.com:443" in the cache.log it led me to believe
this was a feature of "RFC 2616 section 14.23" and that the default setting
of host_verify_strict off would log these errors and allow access to these
sites.

On 3.5.20 the access log appeared to have very few 409 status returns.

Since going to 3.5.25 and now 3.5.27 incase recent changes fixed the
behavior I was seeing there are many 409 status returned in the logs and
many more SSL issues talking to sites like AWS that use a number of IP
address's that might not be able to be verified.

It seems either I use 3.5.20 and restart squid when the FD's get close to
maximum or I have these SSL problems with client connections, what is needed
to try and investigate this further as it appears to have changed with the
bug fix 4508.

Thanks.

Steve.



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users