Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42724AF2.9080702@apache.org>
Date: Fri, 29 Apr 2005 15:55:46 +0100
From: Matthieu Estrade <mestrade@apache.org>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: SSL error trapping
References: <20050429102257.DA210CA584@cmcodec04.st1.spray.net>
 <20050429124613.3FF4FCA584@cmcodec04.st1.spray.net>
In-Reply-To: <20050429124613.3FF4FCA584@cmcodec04.st1.spray.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Could you look how the reason is put in this variable ?

|
SSL_CLIENT_VERIFY| 	string 	|NONE|, |SUCCESS|, |GENEROUS| or 
|FAILED:|/reason/


>     ----- Original Message -----
>     *From:* sternmarc@lycos.co.uk <mailto:sternmarc@lycos.co.uk>
>     *To:* dev@httpd.apache.org <mailto:dev@httpd.apache.org>
>     *Sent:* Friday, April 29, 2005 12:26 PM
>     *Subject:* SSL error trapping
>
>     In case a SSL connection fails because a certificate is expired,
>     or a CRL is unavailable, etc., the browser receives a SSL error
>     that results in a cryptic technical error displayed to the user -
>     sometimes only an error number like in Firefox. In such a
>     situation, the SSL connection could be established, and a
>     HTTP_FORBIDDEN (403) error returned. By adding another module, It
>     is even possible to trap the exact SSL error and redirect to a
>     page with the specific error message ("Your certificate is
>     expired", "We cannot check the validity of the certificate - retry
>     later", ..).
>      
>     I plan to add all of this, but I'd like to check with everybody
>     the best design and implementation.
>      
>     *_Technical description (based on 2.0.54):_*
>     In ssl_io_filter_connect( (ssl_engine_io.c), we have 2 cases (at
>     line 1147 and 1173) where the connection may break because of
>     certificates verification/validation problem:  ' return
>     ssl_filter_io_shutdown(filter_ctx, c, 1); '
>     If we do not return, we can trap the error in 'ssl_hook_Access( )'
>     (ssl_engine_kernel.c).
>     At the end, instead of returning DECLINED, we have to check the
>     certification verification result, then return either DECLINED or
>     HTTP_FORBIDDEN.
>     This is quite generic; then we may use another module to make
>     redirections depending on the exact error.
>      
>     *_Questions and choices:_*
>      
>     1. Could this be accepted as a standard feature (thus for
>     everybody), or should I use
>         - a compilation flag
>         - a run-time directive
>      
>     2. Does the other module trapping the 'hook_access' receive the
>     control in case of the previous module returns a HTTP_FORBIDDEN
>     error ?
>     If not, we could detect at run-time that the trapping module is
>     loaded (how exactly ?), and, in this case, return DECLINED.
>      
>     3. To check the certification verification process, I can use the
>     string "SSL_CLIENT_VERIFY", but isn't there any real error code
>     (int) available ? It would be cleaner to use the exact OpenSSL
>     error codes than a string. I cannot find this code, even inside
>     'ssl_hook_Access( )' in ssl_engine_kernel.c. Awk ...
>      
>     4. Should this trapping be extended to other non fatal SSL errors
>     ? Is it also possible to trap fatal errors and redirect to HTTP ?
>      
>     If you have other remarks or ideas, please tell me.
>      
>     Marc
>