[squid-users] Question about squid-3.5-13849.patch

[Amos Jeffries]

On 9/07/2015 2:33 a.m., Paulo Matias wrote:
> Hi,
> 
> On 07-07-2015 11:05, Amos Jeffries wrote:
>> On 8/07/2015 1:37 a.m., dweimer wrote:
>>> System is Running on FreeBSD 10.1-RELEASE-p14, using OpenSSL included in
>>> base FreeBSD.
>>
>> No, the change is automatic for all Squid built against an OpenSSL
>> library that supports the library API option. If it is not working, then
>> the library you are using probably does not support that option.
>>
>> AFAIK you need at least OpenSSL 0.9.8m for anything related to that
>> vulnerability to be fixable. The latest 1.x libraries do not support the
>> flag we use because they do the rejection internally without needing any
>> help from Squid.
> 
> Unfortunately this seems not to be the case. I have installed
> FreeBSD 10.1-RELEASE-p14 in a VM for testing. Running "openssl version"
> reports "OpenSSL 1.0.1l-freebsd 15 Jan 2015". I was able to reproduce
> Dean's issue (renegotiation does not get disabled), but I was not able
> to fix it so far.
> 
> For OpenSSL version comparison purposes, Debian wheezy (which the patch
> was able to harden) ships 1.0.1e. Debian jessie (which was already hardened
> out-of-the-box, without the patch) ships 1.0.1k. It is strange that FreeBSD's
> more recent OpenSSL version (1.0.1l) presents the issue.
> 
> The SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS define exists in FreeBSD OpenSSL headers,
> the relevant code gets compiled in squid executable, SSL_CTX_set_info_callback
> runs, but *the ssl_info_cb callback is never called* (I tested by inserting
> a debug message inside the "#if defined", just after SSL_CTX_set_info_callback,
> and another one at the beginning of the callback).

That would be a nasty bug in the FreeBSD OpenSSL then.

(FreeBSD 10 is growing an annoying set of bugs; libpthreads not working,
OS signals not working, now OpenSSL not working...)

> 
> Maybe we could try to adapt nginx's solution, but it does not seem to be
> trivial to do that in the current codebase
> https://github.com/nginx/nginx/commit/70bd187c4c386d82d6e4d180e0db84f361d1be02
> 

They are using the same SSL_CTX_set_info_callback() mechanism we are to
set the initial flag which triggers errors. If the callback itself is
not being run their fix will not work either.

Amos