Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
Received-SPF: unknown domain:google.com (nike.apache.org: encountered
 unrecognized mechanism during SPF processing of domain of kyanha@kyanha.net)
From: "Kyle Hamilton" <kyanha@kyanha.net>
To: docs@httpd.apache.org
Date: Tue, 17 Apr 2012 14:51:31 -0700 (Pacific Daylight Time)
Message-ID: <h15hm6ny7srm9zeidijezwJv4X.penango@mail.gmail.com>
Subject: Documentation for Apache httpd SSLVerifyClient considered harmful
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
	micalg="sha1"; boundary=gmsm1.9.6eqh15hm6pj30n0szbhi22

--gmsm1.9.6eqh15hm6pj30n0szbhi22
Content-Type: text/plain; format=flowed; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

--gmsm1.9.6eqh15hm6pj30n0szbhi22
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Verify This Message with Penango.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g
AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll
VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK
b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV
BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n
JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky
zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII
WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb
pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID
AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv
7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC
ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0
c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p
bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM
aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v
Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov
L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo
pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r
+6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0
CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S
qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi
GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln
bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll
bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTIwNDE3MjE1MTMxWjAjBgkqhkiG9w0BCQQxFgQUMZiGaTh/uuteBJyjZbLiRuTz
0PAwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA
BIIBAKzap8qRh65+ZIawQpRgJYyEsiLah8fDefEvptadeqSGX/RElrR2y5Pc6u9UFECraUNDBWGE
EUbvVkzE7ig8pW9VRkdK/wtO0TD38htWRGr8VcFRD1B2VD/EWdtGpCMeu6Qnngk0xAyhZOQNLWAu
pskZllmbA2j0uBbl7VqPbqoUcTgthQ+VTKR1CmcAAfv5QBZksKAfStJ0D9Ycm6RaiL2gVoKxwI3p
DSxozDAzHWAF9Sb073u/EFjWN7DcwzC6T+zu/i56gTr9rJ2kGWGSHNiirJT/NJAwsB+Hh4HR+dea
vvQCO6SaV9xUo3FsWF3pTEMSF2EZSvKtsg6oDv2yLuUAAAAAAAA=
--gmsm1.9.6eqh15hm6pj30n0szbhi22--