--00163646babce3dfa6047ac5e1d7
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have a setup where Apache 2.2.3 is serving a large SVN repository with
WebDAV over HTTPS (using basic authentication).

Everything is working correctly; I would simply like to force usage of
faster cipher algorithms (trading some security in favor of speed) than what
seems to be allowed right now (for instance, AES 256 is used when I connect
with Firefox).

My idea is that, by only allowing less secure but faster algorithms, all SVN
clients (command-line SVN or TortoiseSVN, for instance) will be forced to
use these faster algorithms, thus speeding up SVN operations.

I have played quite a bit with the SSLCipherSuite setting (at the virtual
host level), but I apparently cannot manage to force the client to specific
algorithms (RC4 for instance).

As an experiment, I have tried that (at the virtual host level):

SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL

which, if I understand correctly, should force usage of RC4+RSA if
available, or other algorithms from the "medium" list:

$ openssl ciphers -v 'ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL'
DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128)
Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128)
Mac=MD5
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128)
Mac=SHA1
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128)
Mac=MD5
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128)
Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128)
Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128)
Mac=MD5

Yet, Firefox still seems to be able to negotiate using AES 256. I am
puzzled.

Am I using the SSLCipherSuite setting correctly? Is there a way (possibly
another way) to achieve this optimization?

For information, I am using Apache/2.2.3 and OpenSSL 0.9.8b 04 May 2006 on
CentOS release 5.2 (Final).

Here is the relevant part of the virtual host configuration:

<VirtualHost XXX.XXX.XXX.XXX:443>
ServerName svn.mydomain.net:443
ServerAdmin "XXX"

DocumentRoot /var/www/vhosts/mydomain.net/subdomains/svn/httpdocs
CustomLog /var/www/vhosts/
mydomain.net/statistics/logs/access_ssl_log plesklog
ErrorLog /var/www/vhosts/mydomain.net/statistics/logs/error_log

SSLEngine on
SSLVerifyClient none
SSLCertificateFile /usr/local/psa/var/certificates/certVl10777

<Directory /var/www/vhosts/mydomain.net/subdomains/svn/httpdocs>
...
</Directory>

SSLProtocol all -SSLv2
SSLHonorCipherOrder on

<Location />
DAV svn
SVNPath /var/www/vhosts/mydomain.net/svn/svnrepository
AuthzSVNAccessFile /var/www/vhosts/
mydomain.net/svn/svn-acl-file
Require valid-user
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /var/www/vhosts/mydomain.net/svn/svn-auth-file
SSLRequireSSL
</Location>
</VirtualHost>

Cheers,
Franz

--00163646babce3dfa6047ac5e1d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I have a setup where Apache 2.2.3 is serving a la=
rge SVN repository=A0with WebDAV=A0over HTTPS (using basic authentication).=
</div><div><br></div><div>Everything is working correctly; =A0I would simpl=
y like to force usage of faster cipher algorithms (trading some security in=
favor of speed) than what seems to be allowed right now (for instance, AES=
256 is used when I connect with Firefox).</div>
<div><br></div><div>My idea is that, by only allowing less secure but faste=
r algorithms, all SVN clients (command-line SVN or TortoiseSVN, for instanc=
e) will be forced to use these faster algorithms, thus speeding up SVN oper=
ations.</div>
<div><br></div><div>I have played quite a bit with the SSLCipherSuite setti=
ng (at the virtual host level), but I apparently cannot manage to force the=
client to specific algorithms (RC4 for instance).</div><div><br></div>
<div>As an experiment, I have tried that (at the virtual host level):</div>=
<div><br></div><div>=A0=A0 =A0 =A0 =A0SSLProtocol all -SSLv2</div><div>=A0=
=A0 =A0 =A0 =A0SSLHonorCipherOrder on</div><div>=A0=A0 =A0 =A0 =A0SSLCipher=
Suite=A0ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL</div>
<div><div><br></div><div>which, if I understand correctly, should force usa=
ge of RC4+RSA if available, or other algorithms from the "medium"=
list:</div><div><br></div><div><div>=A0=A0 =A0 =A0 =A0$ openssl ciphers -v=
'ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL'</div>
<div>=A0=A0 =A0 =A0 =A0DHE-DSS-RC4-SHA =A0 =A0 =A0 =A0 SSLv3 Kx=3DDH =A0 =
=A0 =A0 Au=3DDSS =A0Enc=3DRC4(128) =A0Mac=3DSHA1</div><div>=A0=A0 =A0 =A0 =
=A0KRB5-RC4-MD5 =A0 =A0 =A0 =A0 =A0 =A0SSLv3 Kx=3DKRB5 =A0 =A0 Au=3DKRB5 En=
c=3DRC4(128) =A0Mac=3DMD5</div><div>=A0=A0 =A0 =A0 =A0KRB5-RC4-SHA =A0 =A0 =
=A0 =A0 =A0 =A0SSLv3 Kx=3DKRB5 =A0 =A0 Au=3DKRB5 Enc=3DRC4(128) =A0Mac=3DSH=
A1</div>
<div>=A0=A0 =A0 =A0 =A0RC2-CBC-MD5 =A0 =A0 =A0 =A0 =A0 =A0 SSLv2 Kx=3DRSA =
=A0 =A0 =A0Au=3DRSA =A0Enc=3DRC2(128) =A0Mac=3DMD5</div><div>=A0=A0 =A0 =A0=
=A0RC4-SHA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SSLv3 Kx=3DRSA =A0 =A0 =A0Au=3D=
RSA =A0Enc=3DRC4(128) =A0Mac=3DSHA1</div><div>=A0=A0 =A0 =A0 =A0RC4-MD5 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 SSLv3 Kx=3DRSA =A0 =A0 =A0Au=3DRSA =A0Enc=3DRC=
4(128) =A0Mac=3DMD5</div>
<div>=A0=A0 =A0 =A0 =A0RC4-MD5 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SSLv2 Kx=3DR=
SA =A0 =A0 =A0Au=3DRSA =A0Enc=3DRC4(128) =A0Mac=3DMD5</div><div><br></div><=
div>Yet, Firefox still seems to be able to=A0negotiate=A0using AES 256. =A0=
I am puzzled.</div></div></div><div><div><br></div>
<div>Am I using the SSLCipherSuite setting correctly? =A0Is there a way (po=
ssibly another way) to achieve this optimization? =A0</div><div><br></div><=
/div><div>For information, I am using Apache/2.2.3 and OpenSSL 0.9.8b 04 Ma=
y 2006=A0on CentOS release 5.2 (Final).</div>
<div><br></div><div>Here is the relevant part of the virtual host configura=
tion:</div><div><br></div><div><div><VirtualHost XXX.XXX.XXX.XXX:443>=
</div><div>=A0=A0 =A0 =A0 =A0ServerName <a href=3D"http://svn.mydomain.net:=
443">svn.mydomain.net:443</a></div>
<div>=A0=A0 =A0 =A0 =A0ServerAdmin "XXX"</div><div><br></div><div=
>=A0=A0 =A0 =A0 =A0DocumentRoot /var/www/vhosts/<a href=3D"http://mydomain.=
net/subdomains/svn/httpdocs">mydomain.net/subdomains/svn/htt pdocs</a></div>=
<div>=A0=A0 =A0 =A0 =A0CustomLog =A0/var/www/vhosts/<a href=3D"http://mydom=
ain.net/statistics/logs/access_ssl_log">mydomain.net/statist ics/logs/access=
_ssl_log</a> plesklog</div>
<div>=A0=A0 =A0 =A0 =A0ErrorLog =A0/var/www/vhosts/<a href=3D"http://mydoma=
in.net/statistics/logs/error_log">mydomain.net/statistics/lo gs/error_log</a=
></div><div><br></div><div>=A0=A0 =A0 =A0 =A0SSLEngine on</div><div>=A0=A0 =
=A0 =A0 =A0SSLVerifyClient none</div>
<div>=A0=A0 =A0 =A0 =A0SSLCertificateFile /usr/local/psa/var/certificates/c=
ertVl10777</div><div><br></div><div>=A0=A0 =A0 =A0 =A0<Directory =A0/var=
/www/vhosts/<a href=3D"http://mydomain.net/subdomains/svn/httpdocs">mydomai=
n.net/subdomains/svn/httpdocs</a>></div>
<div>=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...</div><div>=A0=A0 =A0 =A0 =A0<=
/Directory></div><div><br></div><div>=A0=A0 =A0 =A0 =A0SSLProtocol all -=
SSLv2</div><div>=A0=A0 =A0 =A0 =A0SSLHonorCipherOrder on</div><div><br></di=
v><div>=A0=A0 =A0 =A0 =A0<Location /></div><div>
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DAV svn</div><div>=A0=A0 =A0 =A0=A0=A0 =
=A0 =A0 =A0 =A0SVNPath /var/www/vhosts/<a href=3D"http://mydomain.net/svn/s=
vnrepository">mydomain.net/svn/svnrepository</a></div><div>=A0=A0 =A0 =A0=
=A0=A0 =A0 =A0 =A0 =A0AuthzSVNAccessFile /var/www/vhosts/<a href=3D"http://=
mydomain.net/svn/svn-acl-file">mydomain.net/svn/svn-acl-file</a></div>
<div>=A0=A0 =A0 =A0=A0=A0 =A0 =A0 =A0 =A0Require valid-user</div><div>=A0=
=A0 =A0 =A0=A0=A0 =A0 =A0 =A0 =A0AuthType Basic</div><div>=A0=A0 =A0 =A0=A0=
=A0 =A0 =A0 =A0 =A0AuthName "Subversion Repository"</div><div>=A0=
=A0 =A0 =A0=A0=A0 =A0 =A0 =A0 =A0AuthUserFile /var/www/vhosts/<a href=3D"ht=
tp://mydomain.net/svn/svn-auth-file">mydomain.net/svn/svn-au th-file</a></di=
v>
<div>=A0=A0 =A0 =A0=A0=A0 =A0 =A0 =A0 =A0SSLRequireSSL</div><div>=A0=A0 =A0=
=A0 =A0</Location></div><div></VirtualHost></div><div><br></di=
v></div><div>Cheers,</div><div>Franz</div><div><br></div>

--00163646babce3dfa6047ac5e1d7--

François Beaune wrote:
> Hello,
>
> I have a setup where Apache 2.2.3 is serving a large SVN
> repository with WebDAV over HTTPS (using basic authentication).
>
> Everything is working correctly; I would simply like to force usage
> of faster cipher algorithms (trading some security in favor of speed)
> than what seems to be allowed right now (for instance, AES 256 is used
> when I connect with Firefox).

[snip]

> As an experiment, I have tried that (at the virtual host level):
>
> SSLProtocol all -SSLv2
> SSLHonorCipherOrder on
> SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL

I noticed that your VirtualHost container doesn't actually contain the
SSLCipherSuite directive. Are you defining that somewhere else, such as
in the global config scope? Double check to make sure that it's being
defined globally as opposed to being wrapped inside another container
object.

Also, you can use this script to check which ciphers are supported by
your site.

http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd.apache.org
" from the digest: users-digest-unsubscribe [at] httpd.apache.org
For additional commands, e-mail: users-help [at] httpd.apache.org

--0016e659f7b270ac79047ad3b811
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Thanks for your answer. I did add the various versions of
the SSLCipherSuite directive to my virtual host container, sorry if that
wasn't clear.

In the meantime I found that, by inspecting the handshake between
TortoiseSVN and Apache, the connection does use RC4, which is good. Still,
I don't understand why this doesn't happen with Firefox (it always uses AES
256, which shouldn't be allowed, if I understand things correctly). Any
clue?

Cheers,
Franz


On Tue, Dec 15, 2009 at 8:26 PM, Justin Pasher
<justinp [at] newmediagateway.com>wrote:

> Fran=E7ois Beaune wrote:
>
>> Hello,
>>
>> I have a setup where Apache 2.2.3 is serving a large SVN repository with
>> WebDAV over HTTPS (using basic authentication).
>>
>> Everything is working correctly; I would simply like to force usage of
>> faster cipher algorithms (trading some security in favor of speed) than =
what
>> seems to be allowed right now (for instance, AES 256 is used when I conn=
ect
>> with Firefox).
>>
>
> [snip]
>
>
> As an experiment, I have tried that (at the virtual host level):
>>
>> SSLProtocol all -SSLv2
>> SSLHonorCipherOrder on
>> SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL
>>
>
> I noticed that your VirtualHost container doesn't actually contain the
> SSLCipherSuite directive. Are you defining that somewhere else, such as i=
n
> the global config scope? Double check to make sure that it's being define=
d
> globally as opposed to being wrapped inside another container object.
>
> Also, you can use this script to check which ciphers are supported by you=
r
> site.
>
> http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h
>
> --
> Justin Pasher
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe [at] httpd.apache.org
> " from the digest: users-digest-unsubscribe [at] httpd.apache.org
> For additional commands, e-mail: users-help [at] httpd.apache.org
>
>

--0016e659f7b270ac79047ad3b811
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Justin,<div><br></div><div>Thanks for your answer. =A0I did add the var=
ious versions of the=A0SSLCipherSuite directive to=A0my virtual host contai=
ner, sorry if that wasn't clear.</div><div><br></div><div>In the meanti=
me I found that, by inspecting the handshake between TortoiseSVN and Apache=
, the connection does use RC4, which is good. =A0Still, I don't underst=
and why this doesn't happen with Firefox (it always uses AES 256, which=
shouldn't be allowed, if I understand=A0things correctly). =A0Any clue=
?</div>
<div><br></div><div>Cheers,</div><div>Franz</div><div><br></div><div><br><d=
iv class=3D"gmail_quote">On Tue, Dec 15, 2009 at 8:26 PM, Justin Pasher <sp=
an dir=3D"ltr"><<a href=3D"mailto:justinp [at] newmediagateway.com">justinp [at] n=
ewmediagateway.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">Fran=E7ois Beaune wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I have a setup where Apache 2.2.3 is serving a large SVN repository with We=
bDAV over HTTPS (using basic authentication).<br>
<br>
Everything is working correctly; =A0I would simply like to force usage of f=
aster cipher algorithms (trading some security in favor of speed) than what=
seems to be allowed right now (for instance, AES 256 is used when I connec=
t with Firefox).<br>

</blockquote>
<br></div>
[snip]<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As an experiment, I have tried that (at the virtual host level):<br>
<br>
=A0 =A0 =A0 =A0SSLProtocol all -SSLv2<br>
=A0 =A0 =A0 =A0SSLHonorCipherOrder on<br>
=A0 =A0 =A0 =A0SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL<br>
</blockquote>
<br></div>
I noticed that your VirtualHost container doesn't actually contain the =
SSLCipherSuite directive. Are you defining that somewhere else, such as in =
the global config scope? Double check to make sure that it's being defi=
ned globally as opposed to being wrapped inside another container object.<b=
r>

<br>
Also, you can use this script to check which ciphers are supported by your =
site.<br>
<br>
<a href=3D"http://www.lazorsoftware.com/lazorsoft/files/openssl_check.sh" t=
arget=3D"_blank">http://www.lazorsoftware.com/lazorsoft/file s/openssl_check=
..sh</a><br>
<br>
-- <br>
Justin Pasher<br>
<br>
------------------------------------------------------------ ---------<br>
The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL:<a href=3D"http://httpd.apache.org/userslist.html" target=3D"_b=
lank">http://httpd.apache.org/userslist.html</a>> for more info.<br>
To unsubscribe, e-mail: <a href=3D"mailto:users-unsubscribe [at] httpd.apache.or=
g" target=3D"_blank">users-unsubscribe [at] httpd.apache.org</a><br>
=A0" =A0 from the digest: <a href=3D"mailto:users-digest-unsubscribe [at] =
httpd.apache.org" target=3D"_blank">users-digest-unsubscribe [at] httpd.apache.o=
rg</a><br>
For additional commands, e-mail: <a href=3D"mailto:users-help [at] httpd.apache.=
org" target=3D"_blank">users-help [at] httpd.apache.org</a><br>
<br>
</blockquote></div><br></div>

--0016e659f7b270ac79047ad3b811--

François Beaune wrote:
> Hey Justin,
>
> Thanks for your answer. I did add the various versions of
> the SSLCipherSuite directive to my virtual host container, sorry if
> that wasn't clear.
>
> In the meantime I found that, by inspecting the handshake between
> TortoiseSVN and Apache, the connection does use RC4, which is good.
> Still, I don't understand why this doesn't happen with Firefox (it
> always uses AES 256, which shouldn't be allowed, if I
> understand things correctly). Any clue?

Did you try running the shell script to verify that the server is
correctly applying the SSLCipherSuite directive and only offering the
ciphers you have allowed?

http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd.apache.org
" from the digest: users-digest-unsubscribe [at] httpd.apache.org
For additional commands, e-mail: users-help [at] httpd.apache.org

--0016364c7054c2e0a8047adbd25c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 16, 2009 at 5:03 PM, Justin Pasher
<justinp [at] newmediagateway.com>wrote:

> Fran=E7ois Beaune wrote:
>
>> Hey Justin,
>>
>> Thanks for your answer. I did add the various versions of the
>> SSLCipherSuite directive to my virtual host container, sorry if that was=
n't
>> clear.
>>
>> In the meantime I found that, by inspecting the handshake between
>> TortoiseSVN and Apache, the connection does use RC4, which is good. Sti=
ll,
>> I don't understand why this doesn't happen with Firefox (it always uses =
AES
>> 256, which shouldn't be allowed, if I understand things correctly). Any
>> clue?
>>
>
> Did you try running the shell script to verify that the server is correct=
ly
> applying the SSLCipherSuite directive and only offering the ciphers you h=
ave
> allowed?
>
>
> http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h
>
>
Sorry, I had overlooked your suggestion. Here's the output of the script:

$ ./openssl_check.sh svn.mydomain.net
Checking svn.mydomain.net:443 ...
- DHE-DSS-RC4-SHA
- EXP1024-DHE-DSS-RC4-SHA
+ EXP1024-RC4-SHA at Server public key is 2048 bit
- EXP1024-DHE-DSS-DES-CBC-SHA
+ EXP1024-DES-CBC-SHA at Server public key is 2048 bit
- ADH-AES256-SHA
+ DHE-RSA-AES256-SHA at Server public key is 2048 bit
- DHE-DSS-AES256-SHA
+ AES256-SHA at Server public key is 2048 bit
- ADH-AES128-SHA
+ DHE-RSA-AES128-SHA at Server public key is 2048 bit
- 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 at Server public key is 2048 bit
+ EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
+ EXP-EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
- 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 at Server public key is 2048 bit
+ EXP-DES-CBC-SHA at Server public key is 2048 bit
+ EXP-RC2-CBC-MD5 at Server public key is 2048 bit
+ RC4-SHA at Server public key is 2048 bit
+ RC4-MD5 at Server public key is 2048 bit
+ EXP-RC4-MD5 at Server public key is 2048 bit
- DES-CBC3-MD5
- DES-CBC-MD5
+ EXP-RC2-CBC-MD5 at Server public key is 2048 bit
- RC2-CBC-MD5
+ EXP-RC4-MD5 at Server public key is 2048 bit
+ RC4-MD5 at Server public key is 2048 bit
- NULL-SHA
- NULL-MD5

I suspect this isn't correct though, as the list stays the same regardless
of how I set SSLCipherSuite (I did restart Apache after each change to
SSLCipherSuite). Either I'm not using the script correctly, or I'm not
setting SSLCipherSuite correctly, or I'm doing another error. Any idea?

Thanks for your help.

Cheers,
Franz

--0016364c7054c2e0a8047adbd25c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>On Wed, Dec 16, 2009 at 5:03 PM, Justin Pasher <span dir=3D"ltr">=
<<a href=3D"mailto:justinp [at] newmediagateway.com">justinp [at] newmediagateway.=
com</a>></span> wrote:</div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
<div class=3D"im">Fran=E7ois Beaune wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hey Justin,<br>
<br>
Thanks for your answer. =A0I did add the various versions of the SSLCipherS=
uite directive to my virtual host container, sorry if that wasn't clear=
..<br>
<br>
In the meantime I found that, by inspecting the handshake between TortoiseS=
VN and Apache, the connection does use RC4, which is good. =A0Still, I don&=
#39;t understand why this doesn't happen with Firefox (it always uses A=
ES 256, which shouldn't be allowed, if I understand things correctly). =
=A0Any clue?<br>

</blockquote>
<br></div>
Did you try running the shell script to verify that the server is correctly=
applying the SSLCipherSuite directive and only offering the ciphers you ha=
ve allowed?<div><div></div><div class=3D"h5"><br>
<br>
<a href=3D"http://www.lazorsoftware.com/lazorsoft/files/openssl_check.sh" t=
arget=3D"_blank">http://www.lazorsoftware.com/lazorsoft/file s/openssl_check=
..sh</a><br>
<br></div></div></blockquote><div><br></div><div>Sorry, I had overlooked yo=
ur suggestion. =A0Here's the output of the script:</div><div><br></div>=
<div><div><div>$ ./openssl_check.sh <a href=3D"http://svn.mydomain.net">svn=
..mydomain.net</a></div>
<div>Checking <a href=3D"http://svn.mydomain.net:443">svn.mydomain.net:443<=
/a> ...</div><div>=A0=A0- DHE-DSS-RC4-SHA</div><div>=A0=A0- EXP1024-DHE-DSS=
-RC4-SHA</div><div>=A0=A0+ EXP1024-RC4-SHA at Server public key is 2048 bit=
</div><div>
=A0=A0- EXP1024-DHE-DSS-DES-CBC-SHA</div><div>=A0=A0+ EXP1024-DES-CBC-SHA a=
t Server public key is 2048 bit</div><div>=A0=A0- ADH-AES256-SHA</div><div>=
=A0=A0+ DHE-RSA-AES256-SHA at Server public key is 2048 bit</div><div>=A0=
=A0- DHE-DSS-AES256-SHA</div>
<div>=A0=A0+ AES256-SHA at Server public key is 2048 bit</div><div>=A0=A0- =
ADH-AES128-SHA</div><div>=A0=A0+ DHE-RSA-AES128-SHA at Server public key is=
2048 bit</div><div>=A0=A0- DHE-DSS-AES128-SHA</div><div>=A0=A0+ AES128-SHA=
at Server public key is 2048 bit</div>
<div>=A0=A0- EXP-KRB5-RC4-MD5</div><div>=A0=A0- EXP-KRB5-RC2-CBC-MD5</div><=
div>=A0=A0- EXP-KRB5-DES-CBC-MD5</div><div>=A0=A0- EXP-KRB5-RC4-SHA</div><d=
iv>=A0=A0- EXP-KRB5-RC2-CBC-SHA</div><div>=A0=A0- EXP-KRB5-DES-CBC-SHA</div=
><div>=A0=A0- KRB5-RC4-MD5</div>
<div>=A0=A0- KRB5-DES-CBC3-MD5</div><div>=A0=A0- KRB5-DES-CBC-MD5</div><div=
>=A0=A0- KRB5-RC4-SHA</div><div>=A0=A0- KRB5-DES-CBC3-SHA</div><div>=A0=A0-=
KRB5-DES-CBC-SHA</div><div>=A0=A0- ADH-DES-CBC3-SHA</div><div>=A0=A0- ADH-=
DES-CBC-SHA</div><div>=A0=A0- EXP-ADH-DES-CBC-SHA</div>
<div>=A0=A0- ADH-RC4-MD5</div><div>=A0=A0- EXP-ADH-RC4-MD5</div><div>=A0=A0=
+ EDH-RSA-DES-CBC3-SHA at Server public key is 2048 bit</div><div>=A0=A0+ E=
DH-RSA-DES-CBC-SHA at Server public key is 2048 bit</div><div>=A0=A0+ EXP-E=
DH-RSA-DES-CBC-SHA at Server public key is 2048 bit</div>
<div>=A0=A0- EDH-DSS-DES-CBC3-SHA</div><div>=A0=A0- EDH-DSS-DES-CBC-SHA</di=
v><div>=A0=A0- EXP-EDH-DSS-DES-CBC-SHA</div><div>=A0=A0+ DES-CBC3-SHA at Se=
rver public key is 2048 bit</div><div>=A0=A0+ DES-CBC-SHA at Server public =
key is 2048 bit</div>
<div>=A0=A0+ EXP-DES-CBC-SHA at Server public key is 2048 bit</div><div>=A0=
=A0+ EXP-RC2-CBC-MD5 at Server public key is 2048 bit</div><div>=A0=A0+ RC4=
-SHA at Server public key is 2048 bit</div><div>=A0=A0+ RC4-MD5 at Server p=
ublic key is 2048 bit</div>
<div>=A0=A0+ EXP-RC4-MD5 at Server public key is 2048 bit</div><div>=A0=A0-=
DES-CBC3-MD5</div><div>=A0=A0- DES-CBC-MD5</div><div>=A0=A0+ EXP-RC2-CBC-M=
D5 at Server public key is 2048 bit</div><div>=A0=A0- RC2-CBC-MD5</div><div=
>=A0=A0+ EXP-RC4-MD5 at Server public key is 2048 bit</div>
<div>=A0=A0+ RC4-MD5 at Server public key is 2048 bit</div><div>=A0=A0- NUL=
L-SHA</div><div>=A0=A0- NULL-MD5</div><div><br></div><div>I suspect this is=
n't correct though, as the list stays the same regardless of how I set =
SSLCipherSuite (I did restart Apache after each change to SSLCipherSuite). =
=A0Either I'm not using the script correctly, or I'm not setting SS=
LCipherSuite correctly, or I'm doing another error. =A0Any idea?</div>
<div><br></div><div>Thanks for your help.</div><div><br></div></div><div>Ch=
eers,</div><div>Franz</div></div><div><br></div></div></div>

--0016364c7054c2e0a8047adbd25c--

François Beaune wrote:
> Sorry, I had overlooked your suggestion. Here's the output of the script:
>
> $ ./openssl_check.sh svn.mydomain.net <http://svn.mydomain.net>
> Checking svn.mydomain.net:443 <http://svn.mydomain.net:443> ...
> + EXP1024-RC4-SHA at Server public key is 2048 bit
> + EXP1024-DES-CBC-SHA at Server public key is 2048 bit
> + DHE-RSA-AES256-SHA at Server public key is 2048 bit
> + AES256-SHA at Server public key is 2048 bit
> + DHE-RSA-AES128-SHA at Server public key is 2048 bit
> + AES128-SHA at Server public key is 2048 bit
> + EDH-RSA-DES-CBC3-SHA at Server public key is 2048 bit
> + EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
> + EXP-EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
> + DES-CBC3-SHA at Server public key is 2048 bit
> + DES-CBC-SHA at Server public key is 2048 bit
> + EXP-DES-CBC-SHA at Server public key is 2048 bit
> + EXP-RC2-CBC-MD5 at Server public key is 2048 bit
> + RC4-SHA at Server public key is 2048 bit
> + RC4-MD5 at Server public key is 2048 bit
> + EXP-RC4-MD5 at Server public key is 2048 bit
> + EXP-RC2-CBC-MD5 at Server public key is 2048 bit
> + EXP-RC4-MD5 at Server public key is 2048 bit
> + RC4-MD5 at Server public key is 2048 bit
>
> I suspect this isn't correct though, as the list stays the same
> regardless of how I set SSLCipherSuite (I did restart Apache after
> each change to SSLCipherSuite). Either I'm not using the script
> correctly, or I'm not setting SSLCipherSuite correctly, or I'm doing
> another error. Any idea?

Everything with a plus sign is a cipher that is accepted by your apache
server, so given these results, the SSLCipherSuite directive is not
being registered.

Here is the SSLCipherSuite directive that I use on my servers to lock
out insecure ciphers:

SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5

Try setting your config to this value. Obviously this is different than
what you are trying to accomplish, but right now the goal is to figure
out whether the SSLCipherSuite directive is actually being acknowledged.
When you run the openssl_check.sh script again, it should return the
following results:

+ AES256-SHA at Server public key is 1024 bit
+ AES128-SHA at Server public key is 1024 bit
+ DES-CBC3-SHA at Server public key is 1024 bit
+ RC4-SHA at Server public key is 1024 bit
+ RC4-MD5 at Server public key is 1024 bit
+ RC4-MD5 at Server public key is 1024 bit

If you see anything different, then the SSLCipherSuite is not being set
properly. Double check that you don't have multiple SSLCipherSuite
directives set across different files. Also make sure you are not
accidentally setting it within an unintentional container, such as
<Directory> or <VirtualHost>. I know that on CentOS, the default config
file that has the SSL directives actually contains the SSLCipherSuite
directive within a <VirtualHost> container. That threw me off recently
when I was trying to setup apache on a CentOS box for the first time.

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd.apache.org
" from the digest: users-digest-unsubscribe [at] httpd.apache.org
For additional commands, e-mail: users-help [at] httpd.apache.org

--0016364d232bae093c047aea7e62
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Dec 16, 2009 at 7:00 PM, Justin Pasher
<justinp [at] newmediagateway.com>wrote:

[snip]

Here is the SSLCipherSuite directive that I use on my servers to lock out
> insecure ciphers:
>
> SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5
>
> Try setting your config to this value. Obviously this is different than
> what you are trying to accomplish, but right now the goal is to figure out
> whether the SSLCipherSuite directive is actually being acknowledged. When
> you run the openssl_check.sh script again, it should return the following
> results:
>
> + AES256-SHA at Server public key is 1024 bit
> + AES128-SHA at Server public key is 1024 bit
> + DES-CBC3-SHA at Server public key is 1024 bit
> + RC4-SHA at Server public key is 1024 bit
> + RC4-MD5 at Server public key is 1024 bit
> + RC4-MD5 at Server public key is 1024 bit
>
> If you see anything different, then the SSLCipherSuite is not being set
> properly. Double check that you don't have multiple SSLCipherSuite
> directives set across different files. Also make sure you are not
> accidentally setting it within an unintentional container, such as
> <Directory> or <VirtualHost>. I know that on CentOS, the default config file
> that has the SSL directives actually contains the SSLCipherSuite directive
> within a <VirtualHost> container. That threw me off recently when I was
> trying to setup apache on a CentOS box for the first time.


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?

Cheers,
Franz

--0016364d232bae093c047aea7e62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Dec 16, 2009 at 7:00 PM, Justin Pasher <=
span dir=3D"ltr"><<a href=3D"mailto:justinp [at] newmediagateway.com">justinp=
[at] newmediagateway.com</a>></span> wrote:<div><br></div><div>[snip]</div><=
div>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex;">
Here is the SSLCipherSuite directive that I use on my servers to lock out i=
nsecure ciphers:<br>
<br>
SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5<br>
<br>
Try setting your config to this value. Obviously this is different than wha=
t you are trying to accomplish, but right now the goal is to figure out whe=
ther the SSLCipherSuite directive is actually being acknowledged. When you =
run the openssl_check.sh script again, it should return the following resul=
ts:<br>

<br>
=A0+ AES256-SHA at Server public key is 1024 bit<br>
=A0+ AES128-SHA at Server public key is 1024 bit<br>
=A0+ DES-CBC3-SHA at Server public key is 1024 bit<br>
=A0+ RC4-SHA at Server public key is 1024 bit<br>
=A0+ RC4-MD5 at Server public key is 1024 bit<br>
=A0+ RC4-MD5 at Server public key is 1024 bit<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">If you see anything differ=
ent, then the SSLCipherSuite is not being set properly. Double check that y=
ou don't have multiple SSLCipherSuite directives set across different f=
iles. Also make sure you are not accidentally setting it within an unintent=
ional container, such as <Directory> or <VirtualHost>. I know t=
hat on CentOS, the default config file that has the SSL directives actually=
contains the SSLCipherSuite directive within a <VirtualHost> contain=
er. That threw me off recently when I was trying to setup apache on a CentO=
S box for the first time.</blockquote>
<div><br></div><div>I'm still getting the same list, even if I use the =
SSLCipherSuite you suggested, so it's clearly not used.</div><div><br><=
/div><div>On my side (in my subdomain's configuration), I only have one=
SSLCipherSuite=A0occurrence, inside the <VirtualHost> container I sh=
own earlier in this thread (and it's not in a <Location> or <D=
irectory> container).</div>
<div><br></div><div>That being said, in /etc/httpd/conf.d/ssl.conf, there i=
s another occurrence:</div><div><br></div><div>=A0=A0 =A0<VirtualHost _d=
efault_:443></div><div>=A0=A0 =A0 =A0 =A0...</div><div><div>=A0=A0 =A0 =
=A0 =A0SSLEngine on</div>
<div>=A0=A0 =A0 =A0 =A0SSLProtocol all -SSLv2</div><div>=A0=A0 =A0 =A0 =A0S=
SLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW</div><div>=
=A0=A0 =A0 =A0 =A0...</div><div>=A0=A0 =A0</VirtualHost></div></div><=
div><br></div><div></div></div>Shouldn't my configuration file have pre=
cedence over that?<div>
<br><div>Cheers,</div><div>Franz</div><div><br></div></div>

--0016364d232bae093c047aea7e62--

François Beaune wrote:
> On Wed, Dec 16, 2009 at 7:00 PM, Justin Pasher
> <justinp [at] newmediagateway.com <mailto:justinp [at] newmediagateway.com>> wrote:
>
> [snip]
>
> Here is the SSLCipherSuite directive that I use on my servers to
> lock out insecure ciphers:
>
> SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5
>
>
> 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.

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd.apache.org
" from the digest: users-digest-unsubscribe [at] httpd.apache.org
For additional commands, e-mail: users-help [at] httpd.apache.org

--002215b01c4a8bc81f047b925e81
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 17, 2009 at 6:21 PM, Justin Pasher
<justinp [at] newmediagateway.com>wrote:

> Fran=E7ois 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 y=
ou
> at least know where it's picking up the setting. As far as WHY it's hitti=
ng
> that VirtualHost container, Apache should be falling back to that one if
> there is no other matching <VirtualHost> container for the request. Looki=
ng
> 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 th=
e
> box has multiple IP addresses assigned and the request is actually hittin=
g
> 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 addres=
s
> (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 i=
s
> 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 th=
e
> 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. Fo=
r
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

--002215b01c4a8bc81f047b925e81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Thu, Dec 17, 2009 at 6:21 PM, Justin Pasher <span dir=3D"ltr"><<=
a href=3D"mailto:justinp [at] newmediagateway.com">justinp [at] newmedia gateway.com</=
a>></span> wrote:</div><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
Fran=E7ois Beaune wrote:</blockquote><div><br></div><div>[snip]</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"></div><div class=3D"im">
I'm still getting the same list, even if I use the SSLCipherSuite you s=
uggested, so it's clearly not used.<br>
<br>
On my side (in my subdomain's configuration), I only have one SSLCipher=
Suite occurrence, inside the <VirtualHost> container I shown earlier =
in this thread (and it's not in a <Location> or <Directory>=
container).<br>

<br>
That being said, in /etc/httpd/conf.d/ssl.conf, there is another occurrence=
:<br>
<br>
=A0 =A0<VirtualHost _default_:443><br>
=A0 =A0 =A0 =A0...<br>
=A0 =A0 =A0 =A0SSLEngine on<br>
=A0 =A0 =A0 =A0SSLProtocol all -SSLv2<br>
=A0 =A0 =A0 =A0SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIU=
M:+LOW<br>
=A0 =A0 =A0 =A0...<br>
=A0 =A0</VirtualHost><br>
<br>
Shouldn't my configuration file have precedence over that?<br>
</div></blockquote>
<br>
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&#=
39;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 W=
HY it's hitting that VirtualHost container, Apache should be falling ba=
ck to that one if there is no other matching <VirtualHost> container =
for the request. Looking back at the original post, I see this...<div class=
=3D"im">
<br>
<br>
<VirtualHost XXX.XXX.XXX.XXX:443><br>
=A0 =A0 =A0 ServerName <a href=3D"http://svn.mydomain.net:443" target=3D"_=
blank">svn.mydomain.net:443</a><br></div>
....<br>
</VirtualHost><br>
<br>
So I assume that the request is actually being made to the (masked) IP addr=
ess 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 th=
e 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 (12=
7.0.0.1), so it would also fall back to the default. Additional note: you d=
on't need the ":443" on the ServerName.<br>

<br>
Now, if changing the SSLCipherSuite in the default VirtualHost does NOT reg=
ister 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.<div>
<div></div><div class=3D"h5"></div></div></blockquote></div><br></div><div>=
<br></div><div>Getting back to this problem only now.</div><div><br></div><=
div>I tried changing the SSLCipherSuite directive in=A0/etc/httpd/conf.d/ss=
l.conf (in the=A0<VirtualHost _default_:443> container), but that had=
no effect. =A0However, I also tried adding a global SSLCipherSuite directi=
ve outside any container, and that had the intended effect:</div>
<div><br></div><div><div>$ ./openssl_check.sh <a href=3D"http://svn.mydomai=
n.net">svn.mydomain.net</a></div><div>Checking <a href=3D"http://svn.mydoma=
in.net:443">svn.mydomain.net:443</a> ...</div><div>=A0=A0- DHE-DSS-RC4-SHA<=
/div>
<div>=A0=A0- EXP1024-DHE-DSS-RC4-SHA</div><div>=A0=A0- EXP1024-RC4-SHA</div=
><div>=A0=A0- EXP1024-DHE-DSS-DES-CBC-SHA</div><div>=A0=A0- EXP1024-DES-CBC=
-SHA</div><div>=A0=A0- ADH-AES256-SHA</div><div>=A0=A0- DHE-RSA-AES256-SHA<=
/div><div>=A0=A0- DHE-DSS-AES256-SHA</div>
<div>=A0=A0+ AES256-SHA at Server public key is 2048 bit</div><div>=A0=A0- =
ADH-AES128-SHA</div><div>=A0=A0- DHE-RSA-AES128-SHA</div><div>=A0=A0- DHE-D=
SS-AES128-SHA</div><div>=A0=A0+ AES128-SHA at Server public key is 2048 bit=
</div><div>=A0=A0- EXP-KRB5-RC4-MD5</div>
<div>=A0=A0- EXP-KRB5-RC2-CBC-MD5</div><div>=A0=A0- EXP-KRB5-DES-CBC-MD5</d=
iv><div>=A0=A0- EXP-KRB5-RC4-SHA</div><div>=A0=A0- EXP-KRB5-RC2-CBC-SHA</di=
v><div>=A0=A0- EXP-KRB5-DES-CBC-SHA</div><div>=A0=A0- KRB5-RC4-MD5</div><di=
v>=A0=A0- KRB5-DES-CBC3-MD5</div>
<div>=A0=A0- KRB5-DES-CBC-MD5</div><div>=A0=A0- KRB5-RC4-SHA</div><div>=A0=
=A0- KRB5-DES-CBC3-SHA</div><div>=A0=A0- KRB5-DES-CBC-SHA</div><div>=A0=A0-=
ADH-DES-CBC3-SHA</div><div>=A0=A0- ADH-DES-CBC-SHA</div><div>=A0=A0- EXP-A=
DH-DES-CBC-SHA</div><div>
=A0=A0- ADH-RC4-MD5</div><div>=A0=A0- EXP-ADH-RC4-MD5</div><div>=A0=A0- EDH=
-RSA-DES-CBC3-SHA</div><div>=A0=A0- EDH-RSA-DES-CBC-SHA</div><div>=A0=A0- E=
XP-EDH-RSA-DES-CBC-SHA</div><div>=A0=A0- EDH-DSS-DES-CBC3-SHA</div><div>=A0=
=A0- EDH-DSS-DES-CBC-SHA</div>
<div>=A0=A0- EXP-EDH-DSS-DES-CBC-SHA</div><div>=A0=A0+ DES-CBC3-SHA at Serv=
er public key is 2048 bit</div><div>=A0=A0- DES-CBC-SHA</div><div>=A0=A0- E=
XP-DES-CBC-SHA</div><div>=A0=A0- EXP-RC2-CBC-MD5</div><div>=A0=A0+ RC4-SHA =
at Server public key is 2048 bit</div>
<div>=A0=A0+ RC4-MD5 at Server public key is 2048 bit</div><div>=A0=A0- EXP=
-RC4-MD5</div><div>=A0=A0- DES-CBC3-MD5</div><div>=A0=A0- DES-CBC-MD5</div>=
<div>=A0=A0- EXP-RC2-CBC-MD5</div><div>=A0=A0- RC2-CBC-MD5</div><div>=A0=A0=
- EXP-RC4-MD5</div><div>
=A0=A0+ RC4-MD5 at Server public key is 2048 bit</div><div>=A0=A0- NULL-SHA=
</div><div>=A0=A0- NULL-MD5</div><div><br></div></div><div>It's basical=
ly the list you mentioned (except for=A0the size of the public keys).</div>=
<div><br></div>
<div>So, it looks like none of the SSLCipherSuite directives inside virtual=
host containers have any effect, only the global one has.</div><div><br></=
div><div>What I don't understand is that the other directives do have a=
n effect. =A0For instance, the <Location /> block defined in the=A0<s=
pan class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; fon=
t-size: 13px; border-collapse: collapse; "><VirtualHost XXX.XXX.XXX.XXX:=
443> container<span class=3D"Apple-style-span" style=3D"border-collapse:=
separate; font-family: arial; font-size: small; ">=A0is definitely taken i=
nto account, as my SVN repository is properly served by Apache (everything =
is working perfectly). =A0Similarly, at some point I added=A0LimitRequestBo=
dy and=A0LimitXMLRequestBody directives to this virtual host container, and=
they had the intended effect. =A0Why would it be different for SSLCipherSu=
ite?</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; "><br>
</span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam=
ily: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span=
class=3D"Apple-style-span" style=3D"border-collapse: separate; font-family=
: arial; font-size: small; ">Thanks for your help.</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; "><br>
</span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam=
ily: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span=
class=3D"Apple-style-span" style=3D"border-collapse: separate; font-family=
: arial; font-size: small; ">Cheers,</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; ">Franz</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; "><br>
</span></span></div>

--002215b01c4a8bc81f047b925e81--