httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Hamilton" <kya...@kyanha.net>
Subject Documentation for Apache httpd SSLVerifyClient considered harmful
Date Tue, 17 Apr 2012 21:51:31 GMT
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

Mime
View raw message