Summary: | SSLCipherSuite can be bypassed during renegotiation | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | keilh <hartmut.keil> |
Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | CLOSED FIXED | ||
Severity: | major | ||
Priority: | P3 | ||
Version: | 2.0-HEAD | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | All |
Description
keilh
2004-10-01 14:30:11 UTC
Thanks for reporting and fixing this, Hartmut. Since this is a security issue, it has been assigned CVE name CAN-2004-0885 for tracking purposes. OK, this patch is not of course sufficient to fix the security issue since it only enforces the correct behaviour with OpenSSL 0.9.7. To actually prevent access with both 0.9.7 and 0.9.6, it's necessary to enhance SSL_hook_Access to really check that the correct cipher suite has been negotiated. To make it working also with OpenSSL 0.9.6 you have to use SSL_CTX_set_session_id_context(..) for disabling a sucessfull cache lookup. But I would skipp supporting OpenSSL 0.9.6 for that special case, and just add the mentioned cipher check. That check would trigger for OpenSSL 0.9.6 and we have a clear situation. This is what I committed: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_kernel.c?r1=1.110&r2=1.111 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_init.c?r1=1.128&r2=1.129 so now with 0.9.6 you'll simply get a 403 if you try and access a differently-ciphersuite-protected resource with a client which tries to resume a session during the renegotiation, and the ciphersuite in the resumed session is not sufficient. With 0.9.7 even with such a client, you shouldn't hit the check since OpenSSL will refuse to resume the session. This should have all bases covered, have I missed anything? Proposed for backport for the next 2.0 release. For reference for those looking for an equivalent mod_ssl 2.8 patch: http://marc.theaimsgroup.com/?l=apache-modssl&m=109724918128044&q=raw |