On 27/07/2013 3:30 a.m., Tsantilas Christos wrote:
On 07/26/2013 03:49 PM, Amos Jeffries wrote:
On 26/07/2013 10:20 p.m., Tsantilas Christos wrote:
This patch try to detect infinite OpenSSL validation loops.

If OpenSSL is stuck in a validation loop, Squid breaks the loop and
triggers a new custom SQUID_X509_V_ERR_INFINITE_VALIDATION SSL
validation error.
That error cannot be bypassed using sslproxy_cert_error because to break
the loop Squid has to tell OpenSSL that the certificate is invalid,
which terminates the SSL connection.

The cause for this patch is the following bug in Openssl (but maybe in
future other similar problems found):
http://rt.openssl.org/Ticket/Display.html?id=3090 (login with
guest/guest)

This is a Measurement Factory project
Please make the validation counter a fixed-size (uint16/32/64_t) and add
a note where SQUID_CERT_VALIDATION_ITERATION_MAX is defined about what
the absolute upper MAX limit that can be defined for the loop is.
I will use an uint32_t type, and I will add a comment about the maximum
value...
However it is not important, I do not believe that someone will use a
higher number than the already defined number...
Actually I believe that any number greater than 100 is not needed here...

Yes quite probably. I'm just wanting to ensure that there is a consistent upper limit here across all Squid builds and installations, and assuming int is >32-bit on Hurd machines can be a mistake.

The default value should be whatever seems reasonable to you. We don't want it to take too long to find errors, but also cope with even the longest expected chains.


+1. Otherwise fine as far as I can tell. Although I'm not aware enough
about OpenSSL API to fully judge.
I will wait for more comments and I will apply it tomorrow. I remember
complains in squid-mailing list that squid enters infinity loops. Maybe
this is fixes some of these problems...


Ok.

PS. If you can find some of the complainers it would be worth sending them a mail about the proposed patch. But don't stress yourself over that.

Amos

Reply via email to