Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 87622 invoked from network); 8 Jan 2007 13:16:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jan 2007 13:16:10 -0000 Received: (qmail 9048 invoked by uid 500); 8 Jan 2007 13:16:13 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 9009 invoked by uid 500); 8 Jan 2007 13:16:13 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 8998 invoked by uid 99); 8 Jan 2007 13:16:13 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jan 2007 05:16:13 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [195.238.0.199] (HELO PEXAS02.ISP.BELGACOM.BE) (195.238.0.199) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jan 2007 05:16:03 -0800 Received: from [10.129.16.102] ([194.7.54.18]) by PEXAS02.ISP.BELGACOM.BE with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 14:15:41 +0100 Message-ID: <45A24400.2040806@approach.be> Date: Mon, 08 Jan 2007 14:15:44 +0100 From: Marc Stern - Approach User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Development Apache CC: jorton@redhat.com Subject: Bug 35083 - SSL error trapping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 13:15:41.0270 (UTC) FILETIME=[1897EF60:01C73327] X-Virus-Checked: Checked by ClamAV on apache.org I patched mod_ssl to trap SSL errors related to certificate validation, allow the SSL connection anyway, then redirect to an error page. Although this works well, this is not implemented the best way, and I got some feedback on how to do it better. Before implementing it, I'd like to check some points, after an in-depth thought. 1. The current idea is to trap validation-related errors, like certificate expiration/revocation. Shouldn't we also trap negotiation errors, like incompatible ciphersuites and protocols between browser and server ? Maybe other ones ? 2. Recommendations are to use one directive to relax the check on certificates (or on ciphersuites, ...), and other ones to trap errors by checking environment variables and redirect the 403 errors to a specific page. a. Doesn't this introduce a security risk, in case the check on certificates is relaxed and the other directives are not set (or changed) ? This is against the principle of secure by installation ... b. This solution would redirect all errors to the same page. Isn't it better to trap the error and redirect to a specific (customisable) page ? Note that this trapping could be implemented in a separate module. I'd like to work soon on this; if you want to participate, please contact me asap. Regards */Marc Stern/* Approach Belgium Avenue Einstein, 2A B-1348 Louvain-la-Neuve Belgium Tel: +32 475 68 29 10 Fax: +32 10 83 22 55 Disclaimer_____________________________________________________________________________ 1. This message is intended for the use of the addressee only and may contain information that is privileged and confidential. 2. If you are not the intended recipient, you are notified that any dissemination of this Communication is strictly prohibited. 3. If you have received this communication in error, please notify us immediately by return of this e-mail. 4. E-mail quotations and proposals are for information only, and are subject to confirmation by the Signature of the appropriate contractual documentation by the authorized persons or both