You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Kyle Hamilton <ky...@kyanha.net> on 2012/04/17 23:51:31 UTC
Documentation for Apache httpd SSLVerifyClient considered harmful
Hello,
I've examined for the past few years where client cryptographic authentication went wrong, and what caused it to be discarded from the minds and workflows of the consumer-facing business and consumer. There are so many aspects to it that I hardly knew where to begin. However, I've traced it ultimately back to the mod_ssl documentation for SSLVerifyClient. In fact, SSLVerifyClient's documentation was one of two major httpd contributions to the Insecure Renegotiation vulnerability. (The other major contributor to the Insecure Renegotiation vulnerability was per-directory TLS authentication, but even that proves less harmful in the final analysis than the documentation for SSLVerifyClient.)
TLS (originally SSL) has a very simplistic error system: the reason code given in a "fatal alert", which causes the connection to be closed and permits no further diagnostic communication (including HTTP redirects). This is less than useful when trying to give self-recovery solutions to the end user of a web application, and is a complete non-starter when designing a new application. The only effective way to take control of the cert auth failure and recovery process is to accept that there will be clients which don't yet have a certificate set up, or which might present the wrong certificate. In any configuration which can handle this, SSLVerifyClient optional_no_ca is the only option.
The documentation for SSLVerifyClient includes this paragraph: "In practice only levels none and require are really interesting. Because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.)"
Setting aside the atrocious grammar, that viewpoint can be correct only (and in its defense is the only correct viewpoint) when static pages are the only application served, or when one does not care about the user experience presented to people in the equivalent of a "wrong password" scenario. Nowadays (10+ years after the documentation was checked in) it's difficult to make a case that static pages are the only applications run upon httpd, and even more difficult to make a case that sites don't care about their authentication flow.
The text of that paragraph causes laypeople to listen to the expert, the person who wrote the documentation. People who read the documentation listen to the writer of the documentation for information to solve their problems. Only people who have explored cryptographic systems have ever considered the possibility that the author of the documentation might be wrong for any reason.
And so, we have applications written by people who did listen to that documentation. Neither Mediawiki, nor phpbb, nor even our banks in US use cryptographic authentication, because of the inflexibility of the fatal TLS alert and its inability to present a graceful error path to the user. Instead, they all bring access control into themselves, not relying upon Apache httpd's access control for either password-based or certificate-based authentication. And those authentication systems still rely upon usernames and passwords, often mixed with "super-cookies".
That is a staggering realization: More than ten (10+) years after mod_ssl officially became part of the Apache httpd project, and fifteen (15) years after the Wassenaar Arrangement permitted open source strong authentication and privacy code to be a legitimate product in international trade, our web-based applications still rely upon usernames and passwords.
And it's all because of that naive, prejudicial paragraph.
That paragraph also made the renegotiation flaw much worse than it had to be, by actively causing people to ignore the only possible way out of the fatal alert quagmire. This led to a lack of business acceptance of user-facing cryptography, which led to a lack of user acceptance of the technology, which led to its languishing by the wayside. If mutual cryptographic authentication had been the norm, it would have been much more difficult if not impossible to exploit that particular flaw.
(The other associated "credential escalation" attack [an MITM attacker injects a privileged URI prior to the TLS authentication renegotiation required by that URI] would not have existed if the capacity to configure per-directory cipher and authentication requirements had not existed. For certificate hostname chicken&egg reasons, it most probably could not have been avoided. However, once Server Name Indication came out and the initial negotiation could /always/ be always mutually authenticated, no matter what name the client expected, this attack also would fail.)
There are certainly many aspects of the ecosystem (most of which were outside of Apache's control) which contributed to the problem. But any single one of them, indeed all of the other aspects combined, would not have been sufficient to break the system had TLS mutual authentication been the norm and not the exception. It would have been, had SSLVerifyClient's documentation not prejudiced httpd's application developers.
For these reasons, the paragraph in question is harmful, and I petition that it be struck from the documentation.
Thank you for your time.
-Kyle H
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Eric Covener <co...@gmail.com>.
Kyle -- please open a bug, preferrably with a patch attached, at
https://issues.apache.org/bugzilla/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Eric Covener <co...@gmail.com>.
> And it's all because of that naive, prejudicial paragraph.
I disagree with this leap as well, FWIW.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Kyle Hamilton <ky...@kyanha.net>.
On Tue, Apr 17, 2012 at 7:26 PM, Eric Covener <co...@gmail.com> wrote:
> Can you elaborate on the suggested update then? Or do you think the
> list of options stands on its own?
The list stands enough on its own that it doesn't need extensive treatment. The only thing I request is that the paragraph that starts with "In practice only" be removed.
For the existing admin, changing the descriptions in the documentation isn't going to make the labels any more or less self-descriptive or change the way their existing applications authenticate. Meanwhile, the new admin will have the same reference documentation that other admins have successfully deployed with, but without the prejudice as to optional_no_ca utility.
I think that the deficiencies in the mod_ssl documentation would be best addressed with a complete rewrite, and Symantec (no affiliation) is offering to do just that. Geoff Noakes has set up a conference call next Monday (April 23) 1pm-2pm PDT on the topic, and I would prefer to address the specifics at that time.
I will happily provide technical review if that's the only thing that would stand in the way of the contribution. I've been working with mod_ssl since before Wassennar in 1998, before it was officially part of httpd.
-Kyle H
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Eric Covener <co...@gmail.com>.
> I actually like Kyle's response here - maybe just add it verbatim?
I don't think it's helpful for the reference manual itself, but could
be rewritten for one of the other free-form SSL sections
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
>
> On 18/04/2012 05:10, Kyle Hamilton wrote:
> >
> >
> > On Tue, Apr 17, 2012 at 6:57 PM, Eric Covener <co...@gmail.com>
> > wrote:
> >>> For these reasons, the paragraph in question is harmful, and I
> >>> petition that
> >>> it be struck from the documentation.
> >>
> >> How about something to the effect of "optional and optional_no_ca
> >> are
> >> useful if you want to validate the certificate yourself, and
> >> generate
> >> your own friendly error response if there's a problem".
> >>
> >> Or, I'm totally misunderstandng the point.
> >
> > "optional" means that you can either accept a certificate from a
> > particularly-named CA, or you want to handle the 403 yourself.
> > Various browsers (including Safari) will not let you send a
> > certificate from a CA which hasn't been named in this circumstance,
> > and will provide a blank credential selection dialog with "OK"
> > greyed
> > out and "Cancel" selected. (This feels like "cancel the connection
> > attempt" more than "cancel sending a certificate".) It is related
> > specifically to TLS/1.0 inability to legally send a blank
> > "acceptable
> > CAs" list.
> >
> > optional_no_ca means that you can accept a certificate from any CA,
> > and you want to handle both the situations where there is no
> > certificate and where there is a certificate from an untrusted CA
> > (both 403) in the application. This is useful where you care more
> > about the key than the information directly bound to it. It's also
> > useful when you want to accept self-signed client certificates that
> > contain multiple credential chains, and handle the additional
> > parsing
> > overhead in your application. This requires TLS/1.1+.
> >
> > optional_no_ca is also the only effective means to handle alternate
> > credential formats which can survive basic X.509 parsing, which
> > again
> > requires TLS/1.1+.
> >
> > -Kyle H
> 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.
+1
> Being a user who's looked at client crypto, never really got it
> working,
> and would love to try again, I'd also be interested in a practical
> explanation of how to use "optional_no_ca" to handle the 403 response
> -
> best if it could be used in a CGI environment - and some more
> information (if there is any) on the Safari issue. Reading your
> paragraph basically (as a user heeding the domain expert) tells me
> "If
> you want to support users on Safari, you're going to have to wrack
> your
> brain for some assbackward solution, or just otherwise give up"
>
> But I love where this is going.
>
> Issac
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 18/04/2012 05:10, Kyle Hamilton wrote:
>
>
> On Tue, Apr 17, 2012 at 6:57 PM, Eric Covener <co...@gmail.com> wrote:
>>> For these reasons, the paragraph in question is harmful, and I
>>> petition that
>>> it be struck from the documentation.
>>
>> How about something to the effect of "optional and optional_no_ca are
>> useful if you want to validate the certificate yourself, and generate
>> your own friendly error response if there's a problem".
>>
>> Or, I'm totally misunderstandng the point.
>
> "optional" means that you can either accept a certificate from a
> particularly-named CA, or you want to handle the 403 yourself.
> Various browsers (including Safari) will not let you send a
> certificate from a CA which hasn't been named in this circumstance,
> and will provide a blank credential selection dialog with "OK" greyed
> out and "Cancel" selected. (This feels like "cancel the connection
> attempt" more than "cancel sending a certificate".) It is related
> specifically to TLS/1.0 inability to legally send a blank "acceptable
> CAs" list.
>
> optional_no_ca means that you can accept a certificate from any CA,
> and you want to handle both the situations where there is no
> certificate and where there is a certificate from an untrusted CA
> (both 403) in the application. This is useful where you care more
> about the key than the information directly bound to it. It's also
> useful when you want to accept self-signed client certificates that
> contain multiple credential chains, and handle the additional parsing
> overhead in your application. This requires TLS/1.1+.
>
> optional_no_ca is also the only effective means to handle alternate
> credential formats which can survive basic X.509 parsing, which again
> requires TLS/1.1+.
>
> -Kyle H
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.
Being a user who's looked at client crypto, never really got it working,
and would love to try again, I'd also be interested in a practical
explanation of how to use "optional_no_ca" to handle the 403 response -
best if it could be used in a CGI environment - and some more
information (if there is any) on the Safari issue. Reading your
paragraph basically (as a user heeding the domain expert) tells me "If
you want to support users on Safari, you're going to have to wrack your
brain for some assbackward solution, or just otherwise give up"
But I love where this is going.
Issac
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Eric Covener <co...@gmail.com>.
Can you elaborate on the suggested update then? Or do you think the
list of options stands on its own?
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Kyle Hamilton <ky...@kyanha.net>.
On Tue, Apr 17, 2012 at 6:57 PM, Eric Covener <co...@gmail.com> wrote:
>> For these reasons, the paragraph in question is harmful, and I petition that
>> it be struck from the documentation.
>
> How about something to the effect of "optional and optional_no_ca are
> useful if you want to validate the certificate yourself, and generate
> your own friendly error response if there's a problem".
>
> Or, I'm totally misunderstandng the point.
"optional" means that you can either accept a certificate from a particularly-named CA, or you want to handle the 403 yourself. Various browsers (including Safari) will not let you send a certificate from a CA which hasn't been named in this circumstance, and will provide a blank credential selection dialog with "OK" greyed out and "Cancel" selected. (This feels like "cancel the connection attempt" more than "cancel sending a certificate".) It is related specifically to TLS/1.0 inability to legally send a blank "acceptable CAs" list.
optional_no_ca means that you can accept a certificate from any CA, and you want to handle both the situations where there is no certificate and where there is a certificate from an untrusted CA (both 403) in the application. This is useful where you care more about the key than the information directly bound to it. It's also useful when you want to accept self-signed client certificates that contain multiple credential chains, and handle the additional parsing overhead in your application. This requires TLS/1.1+.
optional_no_ca is also the only effective means to handle alternate credential formats which can survive basic X.509 parsing, which again requires TLS/1.1+.
-Kyle H
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
<ma...@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
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Kyle Hamilton <ky...@kyanha.net>.
Issac,
I still think that a full rewrite is the best option for the entirety of the mod_ssl documentation, and am looking forward to Symantec's contribution.
That said, if that falls through, I don't think that any specific product name should be mentioned in the documentation unless it's clearly broken. Safari's behavior can indeed be viewed as working-as-designed.
If you want to use that directly, please strike the Safari parenthetical.
Otherwise, I have 4 suggestions (one for each parameter value) below.
On Wed, Apr 18, 2012 at 12:30 AM, Issac Goldstand <ma...@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.
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.)
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.
Applications invoked by httpd receive the certificate data via the environment. This is inhibited by default for performance reasons. SSLOptions +StdEnvVars and/or +ExportCertData must be set for the application to obtain information about the client (and server) certificate chains. +ExportCertData is slightly less expensive than +StdEnvVars inside httpd, at the expense of more time in the application to fully parse the client-provided chain.
> Being a user who's looked at client crypto, never really got it working,
> and would love to try again, I'd also be interested in a practical
> explanation of how to use "optional_no_ca" to handle the 403 response -
> best if it could be used in a CGI environment - and some more
> information (if there is any) on the Safari issue. Reading your
> paragraph basically (as a user heeding the domain expert) tells me "If
> you want to support users on Safari, you're going to have to wrack your
> brain for some assbackward solution, or just otherwise give up"
This is the reason why I consider optional_no_ca to be the only legitimate answer. :) I must mention though, this behavior is not limited to Safari. I first ran across it in Netscape Navigator about 16 years ago, though I haven't checked recently if it's still the case in Mozilla Firefox. That behavior is, according to the TLS RFCs, the legitimate response when a client cert is requested and the client doesn't have any certs from any acceptable CA.
The problem was that TLS/1.0 did not include a means to specify "I want to accept any CA", and the effective response was "okay, we will only show CAs which have been whitelisted". With no client certs that chain to a whitelisted CA, the selection dialog shows all 0 of the whitelisted certs. (According to Nelson Bolyard with Mozilla a few years ago, this was the motivation for the wildcard acceptable CA list in TLS/1.1.)
To handle things in CGI, this is where the environment variables come in. With +ExportCertData, use ${env:SSL_CLIENT_CERT} to get the same information as ${env:SSL_CLIENT_CERT_CHAIN_0} (PEM-encoded client certificate). Then if you need to verify its issuer, check ${env:SSL_CLIENT_CERT_CHAIN_1}, and so on. If you're relying on critical subjectAltNames, this is the only way to obtain them.
If you don't need to worry about subjectAltNames, use +StdEnvVars, and obtain the distinguished identity of the client with $SSL_CLIENT_I_DN.
> But I love where this is going.
This situation has a downside in that there is no standard way (except possibly JavaScript CRMF handling) to request the creation of a keypair of any given type or parameters. Microsoft uses xenroll.dll as an ActiveX component to do so, Mozilla uses <keygen>, and <keygen> is the most well-supported in other browsers. keygen documentation will most likely not be brought under the httpd umbrella, which unfortunately will mean that admins and developers will still need to look elsewhere for the information they need to implement their apps.
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.
-Kyle H
Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Posted by Eric Covener <co...@gmail.com>.
> For these reasons, the paragraph in question is harmful, and I petition that
> it be struck from the documentation.
How about something to the effect of "optional and optional_no_ca are
useful if you want to validate the certificate yourself, and generate
your own friendly error response if there's a problem".
Or, I'm totally misunderstandng the point.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org