On 1/12/2012 7:04 a.m., Thomas Martin wrote:
Hello everyone.
I'm trying to patch Squid3.1 to disable the client-initiated ssl renegotiation.
I read that some users tried to do the same thing:
http://www.squid-cache.org/mail-archive/squid-users/201203/0163.html
I tried the solution of Amos but I can't make it work.
So I tried Squid3.2 and saw that this security issue was fixed on this version.
Now I'm trying to use the Squid3.2 sources to backport into Squid3.1.
Unfortunately I am not making any progress for now.
Since you are building Squid is there any particular reason why you are
not building the currently supported 3.2 sources which as you noticed
are fixed?
AFAIK the fix in Squid was just the change to remove our default
"SSL_OP_ALL" which breaks the OpenSSL protection hack. Possiby combined
with the default of using SSLv3 instead of SSLv2. Renegotiation is one
of the options enabled by "ALL". Note that your config can contain the
ssloption=ALL and cause the renegotiate to happen again. Also notice
that for any of this to work you need to be building against a fixed
version of OpenSSL.
=== modified file 'src/ssl_support.cc'
--- src/ssl_support.cc 2012-02-01 07:55:01 +0000
+++ src/ssl_support.cc 2012-11-30 23:39:04 +0000
@@ -425,7 +425,7 @@
static long
ssl_parse_options(const char *options)
{
- long op = SSL_OP_ALL;
+ long op = 0;
char *tmp;
char *option;
Does someone can help me? At least give me an idea where I have to
look (I didn't see anything about client-initiated renegotiation on
ssl/support.* but I'm really not a great developer)...
Squid contains nothing explicitly about client negotiation. It is all
passed to OpenSSL. The closest that is reached is defaulting to
"SSL_OP_ALL" (fixed by the above patch), the rest is squid.conf options
set by the administrator and passed straight to OpenSSL.
Any help will be really appreciated.
Thanks.
Regards.
NB: Sorry for my English, I know it sucks.
Reads fine to me :-)
Amos
