DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35083>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35083 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-06 10:25 ------- I would like to be sure to not introduce a security risk because of a bad configuration: suppose we use something like "SSLVerifyClient optional_no_ca" and trap the error by activating another directive; if the administrator removes the error trapping, the certificate would be accepted. This is obviously the administrator's fault, but you know about the security failure principle. Shouldn't we replace the check for "SSLVerifyClient optional_no_ca ..." by a check "is error trapping activated" ? Currently, the check controls if the module is loaded (thus activated), but we could imagine a general directive "SSLTrapCertifErrors". Btw, what was the original intend of the "SSLVerifyClient optional_no_ca" directive ? Is it really used ? Because, if we use it as a flag to trap the error, we cannot use the "old way" anymore, so we break the compatibility. To recap, does the following seem better: - we include the whole handling in mod_ssl (no external module) - we add a general directive "SSLTrapCertifErrors" - we put all extra info (error, DN, serial, ...) in environment variables If you prefer a separate module, how to activate it in without either explicitly patching mod_ssl, or accepting all certrificates error in mod_ssl - which I find dangerous as explained above ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
