Bug#327269: apache2 security update breaks ssl+svn

[Adam Conrad <adconrad@debian.org>]

Andreas Jellinghaus wrote:

>On Friday 09 September 2005 02:37, Adam Conrad wrote:
>  
>
>>I would like a tarball of your /etc/apache2/
>>
>if there is anything else I can do to help, please let me know.
>  
>

Meh.  Yeah, this is actually a neon or svn (not sure who) bug, where it
can't do renogotiations when requested, and our fix for the security
hole in apache2 removed a "feature" (that "feature" was the security
hole) you were relying on with your configs.  I need to set up a test
case here and see if there's a good way to do this, so it still works
how you want, without fixing neon/svn (which isn't really an option).

The bug that you were taking advantage of is that if you had
"SSLVerifyClient optional" in your VirtualHost, and "SSLVerifyClient
require" in a Location statement, the latter would never be honoured, so
I could actually get at your SVN repo by refusing to offer a client
cert, and Apache would give me write access.  Whoops.

We've fixed that, but in fixing that, obviously you've tripped on the
above issue.

Could you try, for curiosity's sake, setting "SSLVerifyClient none" in
the main VirtualHost, and keeping the rest the same, and seeing if that
makes a difference for you at all?  Over the weekend, I'll set up a test
SVN site and follow some codepaths around in mod_ssl and see if there's
still a way (short of you using seperate Vhosts for read access and
read/write access, which has been considered by many the "most secure"
option) to have apache behave the way you'd like it to.

... Adam