[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-docs
Subject:    Re: Documentation for Apache httpd SSLVerifyClient considered harmful
From:       Stefan Fritsch <sf () sfritsch ! de>
Date:       2012-04-20 10:21:16
Message-ID: 201204201221.17022.sf () sfritsch ! de
[Download RAW message or body]

On Wednesday 18 April 2012, Kyle Hamilton wrote:
> 
> Otherwise, I have 4 suggestions (one for each parameter value)
> below.
> 
> On Wed, Apr 18, 2012 at 12:30 AM, Issac Goldstand 
<margol@beamartyr.net> wrote:
> > I actually like Kyle's response here - maybe just add it
> > verbatim? Kyle, if you could reword the "none" (trivial) and
> > "require" in the same style, we can completely replace the whole
> > sentence with a more detailed explanation.
> 
> SSLClientVerify none means that no verified TLS credentials shall
> be requested or received from the client, and the application
> shall always be invoked.
> 
> SSLClientVerify require means that if a client does not provide an
> acceptable certificate from a trusted CA in
> SSLCADNRequest{File|Path} (see their docs for their fallbacks),
> the application shall not be invoked, instead relying on Apache
> httpd's ErrorDocument handlers when the client authentication
> fails.  Most clients will not allow unacceptable certificate
> chains to be chosen here, but if they do mod_ssl will verify they
> are correct and acceptable before invoking the application.

This is wrong. If the cert is not acceptable, mod_ssl will reject the 
certificate on the TLS/SSL level, and a (usually confusing) error 
message will be generated by the client. No ErrorDocument will be sent 
by httpd. If this is set in virtual host (and not directory) scope,  
the client will not even get an opportunity to send the request to 
httpd.

> SSLClientVerify optional means that httpd shall request client
> certificate authentication.  If the client does not prove an
> acceptable certificate from a trusted CA in
> SSLCADNRequest{File|Path}, the application will handle the 403
> errorflow itself.  Most clients will not allow unacceptable
> certificates to be chosen here, but if they do mod_ssl will verify
> they are correct and acceptable before invoking the application.
> 
> (I'm actually not quite certain on the specific semantic here. 
> Will 'optional' still place unacceptable certificates in the
> environment with SSLOptions +StdEnvVars and/or +ExportCertData?  I
> don't think it should, but I've not read that code in a very long
> time.)

It's a bit more complex. If the client does not have an acceptable 
certificate, it will usually not send one at all. If no certificate is 
sent to the server, the application will get opportunity to handle  
the 403 errorflow itself. However, if the client sends a certificate 
and that turns out to be unacceptable (be it that it is not signed by 
a trusted CA, or that it is expired, or that it is simply broken), 
mod_ssl will again reject the certificate on the TLS/SSL level. I am 
not quite sure if the client can go on after that, but the 
overwhelming majority of clients will simply disconnect and show some 
error message to the user.

> 
> SSLClientVerify optional_no_ca means that httpd shall request
> client authentication, and the application shall be invoked
> regardless of potential invalidity, unacceptability, or absence of
> the certificate chain provided by the client.  With this
> configuration, the application must handle its own access control.

This is also wrong. If the certificate is invalid for other reasons 
than an invalid trust chain, mod_ssl will again reject the certificate 
on the TLS/SSL level. This means there is currently no way for web 
applications to handle the error by themselves if for example the 
client certificate is expired or has been revoked.

There are some open PRs about this issue, for example PR 45922, PR 
33084. And PR 45054 is also related.

> Seriously, all that needs to be done is get rid of the "in
> practice" paragraph and I'll be happy.  I'd rather get that done
> first before trying to perfect the rest of the prose, and I'd
> rather evaluate Symantec's offer before working on that.

I agree that "SSLVerifyClient optional" is usually the better choice 
than "require". But there are still cases where "require" is the only 
way. For example, I have encountered some Web-Application that needed 
to access some back-end server and failed to send the client 
certificate unless "SSLVerifyClient require" was set. It was running 
in a Websphere Application Server, but I don't know if it was the 
fault of the Web-App or the Application server. This was in 2010 or 
2011, so this can still be a real problem today.

I don't think that "SSLVerifyClient optional_no_ca" has much advantage 
over "optional" until there is also a way to let the web-app handle 
other certificate errors, too. Therefore, I would not recommend it 
until the above bugs are fixed.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]