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). 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 Best regards, Paulo Matias _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
