httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <sternm...@lycos.co.uk>
Subject Re: mod_ssl breaks connection if peer doesn't send client certificate
Date Mon, 08 Aug 2005 13:25:32 GMT
This problem is solved, in a much general manner in mod_ssl_error (see bug 
35083 - http://nagoya.apache.org/bugzilla/show_bug.cgi?id=35083).

Could we include this soon ?
The only decision is about the inclusion:
 - in the distribution, with an option
 - as a separate module, with an option
 - as a separate module, with an automatic detection of the module loading

The current patch proposes the 3rd approach, as I wanted to have the tiniest 
possible modification to the existing code, but both other options are 
trivial.

Marc


----- Original Message ----- 
From: "Daniel Risacher" <magnus@alum.mit.edu>
To: <dev@httpd.apache.org>
Sent: Friday, August 05, 2005 9:52 PM
Subject: mod_ssl breaks connection if peer doesn't send client certificate


>
> If SSLVerifyClient is 'require', but the client doesn't send a
> certificate (e.g. Netscape won't send an expired user cert), then
> mod_ssl breaks the connection before any response can be sent. This
> message appears in the error log: "Re-negotiation handshake failed:
> Not accepted by client!?"
>
> When this happens, the user cannot get an error document that might
> explain how to fix the condition, and (for Netscape and IE) leaves the
> browser confusingly with the new URL in the URL bar, but displaying
> the last sucessfully loaded page.
>
> I conclude that this is a bug in mod_ssl.  I think the problem is that
> if SSLVerifyClient is 'require', then OpenSSL is set to
> SSL_VERIFY_PEER_STRICT.  When OpenSSL fails to verify the client cert,
> it terminates the SSL connection, and therefore no response can be
> sent (even 403 FORBIDDEN).
>
> I suggest that mod_ssl should use SSL_VERIFY_PEER when SSLVerifyClient
> is set to 'require', and let ssl_hook_Access() return HTTP_FORBIDDEN
> when the cert validation fails.  Alternatively, there could be a new
> value for SSLVerifyClient that has that behavior.
>
> Adding a new value for SSLVerifyClient has better backwards
> compatibility, but personally I beleive that the current behavior
> (dropping the connection without an error response) is sufficiently
> broken that httpd shouldn't ever do that.  Any thoughts on which of
> these is better?
>
> -Dan
>
> 


Mime
View raw message