Could you look how the reason is put in this variable ?
|
SSL_CLIENT_VERIFY| string |NONE|, |SUCCESS|, |GENEROUS| or |FAILED:|/reason/
----- Original Message ----- *From:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> *To:* [email protected] <mailto:[email protected]> *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
