Bug 53193 - SLVerifyClient optional_no_ca + SSLSessionCache = wrong SSL_CLIENT_VERIFY
Summary: SLVerifyClient optional_no_ca + SSLSessionCache = wrong SSL_CLIENT_VERIFY
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.2.22
Hardware: PC FreeBSD
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
Depends on:
Blocks:
 
Reported: 2012-05-04 11:56 UTC by AlexSav
Modified: 2018-11-07 21:08 UTC (History)
3 users (show)



Attachments
patch (647 bytes, patch)
2012-11-22 17:10 UTC, Arnis UT
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description AlexSav 2012-05-04 11:56:04 UTC
If I use "SSLVerifyClient optional_no_ca" and SSLSessionCache (with any type of cache, for example "dbm:/var/run/httpd/ssl_scache"), "SSLSessionCacheTimeout 300", from time to time in the CGI environment (I refresh web-page within 1-2 minutes ) I see SSL_CLIENT_VERIFY=SUCCESS, in spite of the client sertifacate in web-browser signed not by the SSLCACertificateFile. It occurs when using Opera browser, because opara provides a selection of client sertificate to authentificate. At the same time possibly other clients works with another virtualhost using valid sertificate (virtualhost works on different port). Even all another ssl-virtualhost was removed and only I accessed the virtualhost with wrong sertificate, the situation is repeated. When I set SSLSessionCache to none, SSL_CLIENT_VERIFY=GENEROUS always. 


 At the same time in log ( when SSL_CLIENT_VERIFY=SUCCESS with wrong sertificate):
10:10:52[debug] ssl_engine_kernel.c(1732): Inter-Process Session Cache: request=GET status=FOUND id=F1FF0E51D83D2BACDFBE4EEE8A348687D402C42BC2CA450E24608375CB82FFB8 (session reuse)
10:10:52 [info] [client 172.16.70.220] SSL client authentication failed, accepting certificate based on SSLVerifyClient optional_no_ca configuration
10:10:52 [debug] ssl_engine_io.c(1897): OpenSSL: read 5/5 bytes from BIO#2bf45300 [mem: 2bfa9000] (BIO dump follows)
10:10:52 [info] Initial (No.1) HTTPS request received for child 71 (server test:443)

10:10:57 [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#2bf45300 [mem: 2bfa9000]
04 10:10:57 [info] [client 172.16.70.220] (70007)The timeout specified has expired: SSL input filter read failed.
04 10:10:57 [debug] ssl_engine_kernel.c(1884): OpenSSL: Write: SSL negotiation finished successfully
04 10:10:57 [info] [client 172.16.70.220] Connection closed to child 97 with standard shutdown (server test:443)
04 10:10:57 [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#2bf45300 [mem: 2bfa9000]
10:10:57 [info] [client 172.16.70.220] (70007)The timeout specified has expired: SSL input filter read failed.
04 10:10:57 [debug] ssl_engine_kernel.c(1884): OpenSSL: Write: SSL negotiation finished successfully
04 10:10:57 [info] [client 172.16.70.220] Connection closed to child 71 with standard shutdown (server test:443)
Comment 1 Arnis UT 2012-11-22 17:10:07 UTC
Created attachment 29622 [details]
patch

Confirmed.
When client certificate is requested in server context and GENEROUS'ly verified session is resumed, the SSL_CLIENT_VERIFY will be set to SUCCESS.

This is security bug for these who rely on SSL_CLIENT_VERIFY to test whether certificate verification was successful.
Comment 2 jkaluza 2014-10-20 09:19:06 UTC
I've been able to reproduce it and verified the patch fixes the issue without indroducing any regression when using perl test suite. Committed in r1633085.
Comment 3 William A. Rowe Jr. 2018-11-07 21:08:05 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.