[squid-users] Disabling client-initiated renegotiation on https_port

Hello guys,

I am running squid as an reverse proxy and can't find a way to disable the support for client initiated renegotiation. I have tested this using

echo "R" | openssl s_client -connect xxxx:443

which returns

RENEGOTIATING
.

The https_port configuration looks like:

https_port 172.16.0.2:443 accel defaultsite=xxxx protocol=https \
    cipher=RC4-SHA:AES256+SHA:AES128+SHA:3DES+SHA:!ADH:!EDH \
    options=ALL:NO_SSLv2,NO_SSLv3,CIPHER_SERVER_PREFERENCE

I have recompiled the centos 6 x86 rpm package using squid 3.1.19. The configure line look like the following:
%configure \
   --exec_prefix=/usr \
   --libexecdir=%{_libdir}/squid \
   --localstatedir=/var \
   --datadir=%{_datadir}/squid \
   --sysconfdir=/etc/squid \
   --with-logdir='$(localstatedir)/log/squid' \
   --with-pidfile='$(localstatedir)/run/squid.pid' \
   --disable-dependency-tracking \
   --enable-arp-acl \
   --enable-follow-x-forwarded-for \
   --enable-auth="basic,digest,ntlm,negotiate" \
   --enable-basic-auth-helpers="LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth" \
   --enable-ntlm-auth-helpers="smb_lm,no_check,fakeauth" \
   --enable-digest-auth-helpers="password,ldap,eDirectory" \
   --enable-negotiate-auth-helpers="squid_kerb_auth" \
   --enable-external-acl-helpers="ip_user,ldap_group,session,unix_group,wbinfo_group" \
   --enable-cache-digests \
   --enable-cachemgr-hostname=localhost \
   --enable-delay-pools \
   --enable-epoll \
   --enable-icap-client \
   --disable-ident-lookups \
   %ifnarch ppc64 ia64 x86_64 s390x
   --with-large-files \
   %endif
   --enable-linux-netfilter \
   --enable-referer-log \
   --enable-removal-policies="heap,lru" \
   --enable-snmp \
   --enable-ssl \
   --enable-storeio="aufs,diskd,ufs" \
   --enable-useragent-log \
   --enable-wccpv2 \
   --enable-esi \
   --enable-http-violations \
   --with-aio \
   --with-default-user="squid" \
   --with-filedescriptors=16384 \
   --with-dl \
   --with-openssl=/root/rpmbuild/BUILD/openssl-1.0.0 \
   --with-pthreads

The referenced openssl source is the build root of the lates RHEL rpm package : openssl-1.0.0-20.el6.2.2.x86_64

rpm -q --changelog openssl | grep CVE

I have found in src/ssl_support.cc that options is initialized with SSL_OP_ALL. The changelog from the openssl package says:

rpm -q --changelog openssl | grep CVE-2009-3555

fix CVE-2009-3555 - note that the fix is bypassed if SSL_OP_ALL is used

so I tried to change my https_port options to start with !ALL but this changes nothing.

I don't know much about the squid or openssl source but after reading the docs for SSL_CTX_set_options I have understand that by default LEGACY_SERVER_CONNECT is set, which enables renegotiation but I assume this applies to the client part of the code only.

From all I have seen nearly anyone (ie apache) has special code added to prevent this renegotiation like the following from the apache 2.2.14 patch:
int state = SSL_get_state(ssl);
+       
+        if (state == SSL3_ST_SR_CLNT_HELLO_A
+            || state == SSL23_ST_SR_CLNT_HELLO_A) {
+            scr->reneg_state = RENEG_ABORT;
+            ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c,
+                          "rejecting client initiated renegotiation");

I was unable to find anything like this within squids source but from other posts I've seen that someone else already fixed this problem but unfortunately it is not clear how.

So now I am wondering what I am doing wrong or if there is no support for disabling this functionality available?

BTW: The openssl version that implements the functionality seem to have SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION as a new constant. To make sure that I recompile against this version I have added this constant to the ssl_options array in ssl_support.cc and the code still compiled fine. So I assume I am using the right version. My next step would be replacing the redhat openssl package with a fresh build from the latest openssl source (without all these redhat patching) but I would prefer if I don't need a custom build as for simple updating.

Many thanks for any ideas / help!

Cheers,
Marcus
Received on Thu Mar 08 2012 - 07:34:19 MST