httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <sternm...@lycos.co.uk>
Subject Re: SSL error trapping
Date Fri, 29 Apr 2005 12:51:19 GMT
Maybe another possibility (?) is to extend the SSL_CVERIFY_OPTIONAL_NO_CA to also suppress
other types of error, although this may be dangerous as, in this case the certificates are
accepted and no error is generated. Can we still trap the error later ?
To investigate ...
  ----- Original Message ----- 
  From: sternmarc@lycos.co.uk 
  To: 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
Mime
View raw message