Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B044BBD.2000504@free.fr>
Date: Wed, 18 Nov 2009 20:32:13 +0100
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.6pre) Gecko/20091116 SeaMonkey/2.0.1pre
MIME-Version: 1.0
To: Stefan Fritsch <sf@sfritsch.de>
CC: dev@httpd.apache.org, Joe Orton <jorton@redhat.com>
Subject: Re: TLS renegotiation disabling : mod_ssl and OpenSSL  0.9.8l
References: <4AF988B2.1000808@free.fr> <200911152253.05879.sf@sfritsch.de>
In-Reply-To: <200911152253.05879.sf@sfritsch.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Fritsch wrote:
> I cannot reproduce the problems. With an openssl that rejects all
> renegotiations, both reconnections after ssl session timeout and
> connections to a host with sslverifyclient optional work fine (with
> openssl s_client).

I have now succeeded in reproducing at least partially the 
"SSLVerifyClient optional" problem, though what I'm testing in not 
exactly the same as you.

I'm testing that with a server where the vhost context has 
"SSLVerifyClient None" and a /authentication directory has 
"SSLVerifyClient optional", requests that alternate between these two 
directory will repeatedly require authentication even when you have 
already authenticated yourself inside the same SSL session.

The setup is the same as in 
https://issues.apache.org/bugzilla/show_bug.cgi?id=48215 , with 
SSLVerifyDepth 0 moved to vhost context in order to work around the 
initial bug 48215 problem.

I just needs the following change in the reproduction steps to reproduce 
from firefox :
- load /
- load /authentification
- just click enter to accept authentication
- press back to return to /
- press F5 to force reload
- load /authentification
- press F5 to force reload
- authentication is requested again by a server initiated renegotiation

Doing this fast enough (less than 4 or 5 seconds between each step), 
Firefox doesn't close the TCP connexion, so it happens inside the same 
already authenticated ssl session, with no ssl session resume involved.

I think that in bug 48228, when I describe that reloading the page 
causes renegotiation, it's the same bug.

So I don't know if Joe prefers that I open another bug for this, or 
wants to handle this in bug 48228.

I have validated that the behavior is the same when the client doesn't 
provide a certificate after the renegotiation. It's not really 
surprising but it's interesting in the light of the case of people 
having set "SSLVerifyClient optional" by error, and not actually using 
client certificates.