On Thu, Dec 17, 2009 at 6:21 PM, Justin Pasher <just...@newmediagateway.com>wrote:
> François Beaune wrote: [snip] > I'm still getting the same list, even if I use the SSLCipherSuite you >> suggested, so it's clearly not used. >> >> On my side (in my subdomain's configuration), I only have one >> SSLCipherSuite occurrence, inside the <VirtualHost> container I shown >> earlier in this thread (and it's not in a <Location> or <Directory> >> container). >> >> That being said, in /etc/httpd/conf.d/ssl.conf, there is another >> occurrence: >> >> <VirtualHost _default_:443> >> ... >> SSLEngine on >> SSLProtocol all -SSLv2 >> SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW >> ... >> </VirtualHost> >> >> Shouldn't my configuration file have precedence over that? >> > > So now we know how Firefox is still using AES256. It's just a matter of > figuring out why the SSLCipherSuite is not being used. The first thing I'd > try is replacing the SSLCipherSuite directory you found above (inside the > <VirtualHost _default_:443> container). If that fixes the problem, then you > at least know where it's picking up the setting. As far as WHY it's hitting > that VirtualHost container, Apache should be falling back to that one if > there is no other matching <VirtualHost> container for the request. Looking > back at the original post, I see this... > > > <VirtualHost XXX.XXX.XXX.XXX:443> > ServerName svn.mydomain.net:443 > ... > </VirtualHost> > > So I assume that the request is actually being made to the (masked) IP > address XXX.XXX.XXX.XXX? One thought out from left field would be that the > box has multiple IP addresses assigned and the request is actually hitting > YYY.YYY.YYY.YYY instead of XXX.XXX.XXX.XXX, which would make it fall back to > the default VirtualHost:443, I believe. Also, if you are trying to access > the server via localhost, that would be coming from a different IP address > (127.0.0.1), so it would also fall back to the default. Additional note: you > don't need the ":443" on the ServerName. > > Now, if changing the SSLCipherSuite in the default VirtualHost does NOT > register the change, then it would sound like it's not hitting ANY of the > VirtualHost containers that have SSLCipherSuite defined. If that really is > the case, you could always put the SSLCipherSuite in the global scope as a > last resort, but ideally you could figure out why it's not recognizing the > setting. > Getting back to this problem only now. I tried changing the SSLCipherSuite directive in /etc/httpd/conf.d/ssl.conf (in the <VirtualHost _default_:443> container), but that had no effect. However, I also tried adding a global SSLCipherSuite directive outside any container, and that had the intended effect: $ ./openssl_check.sh svn.mydomain.net Checking svn.mydomain.net:443 ... - DHE-DSS-RC4-SHA - EXP1024-DHE-DSS-RC4-SHA - EXP1024-RC4-SHA - EXP1024-DHE-DSS-DES-CBC-SHA - EXP1024-DES-CBC-SHA - ADH-AES256-SHA - DHE-RSA-AES256-SHA - DHE-DSS-AES256-SHA + AES256-SHA at Server public key is 2048 bit - ADH-AES128-SHA - DHE-RSA-AES128-SHA - DHE-DSS-AES128-SHA + AES128-SHA at Server public key is 2048 bit - EXP-KRB5-RC4-MD5 - EXP-KRB5-RC2-CBC-MD5 - EXP-KRB5-DES-CBC-MD5 - EXP-KRB5-RC4-SHA - EXP-KRB5-RC2-CBC-SHA - EXP-KRB5-DES-CBC-SHA - KRB5-RC4-MD5 - KRB5-DES-CBC3-MD5 - KRB5-DES-CBC-MD5 - KRB5-RC4-SHA - KRB5-DES-CBC3-SHA - KRB5-DES-CBC-SHA - ADH-DES-CBC3-SHA - ADH-DES-CBC-SHA - EXP-ADH-DES-CBC-SHA - ADH-RC4-MD5 - EXP-ADH-RC4-MD5 - EDH-RSA-DES-CBC3-SHA - EDH-RSA-DES-CBC-SHA - EXP-EDH-RSA-DES-CBC-SHA - EDH-DSS-DES-CBC3-SHA - EDH-DSS-DES-CBC-SHA - EXP-EDH-DSS-DES-CBC-SHA + DES-CBC3-SHA at Server public key is 2048 bit - DES-CBC-SHA - EXP-DES-CBC-SHA - EXP-RC2-CBC-MD5 + RC4-SHA at Server public key is 2048 bit + RC4-MD5 at Server public key is 2048 bit - EXP-RC4-MD5 - DES-CBC3-MD5 - DES-CBC-MD5 - EXP-RC2-CBC-MD5 - RC2-CBC-MD5 - EXP-RC4-MD5 + RC4-MD5 at Server public key is 2048 bit - NULL-SHA - NULL-MD5 It's basically the list you mentioned (except for the size of the public keys). So, it looks like none of the SSLCipherSuite directives inside virtual host containers have any effect, only the global one has. What I don't understand is that the other directives do have an effect. For instance, the <Location /> block defined in the <VirtualHost XXX.XXX.XXX.XXX:443> container is definitely taken into account, as my SVN repository is properly served by Apache (everything is working perfectly). Similarly, at some point I added LimitRequestBody and LimitXMLRequestBody directives to this virtual host container, and they had the intended effect. Why would it be different for SSLCipherSuite? Thanks for your help. Cheers, Franz
