Re: Using SSLCipherSuite to restrict to faster cipher algorithms (Apache Users)

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.

$ ./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

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?