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
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
