httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject SSL error trapping
Date Fri, 29 Apr 2005 10:26:51 GMT
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.

View raw message