On Mon, Mar 11, 2002 at 09:18:08AM +0100, Joerg Bartholdt wrote:
> Dr S N Henson wrote:
>
> >Joerg Bartholdt wrote:
> >
> >>Hi *,
> >>
> >>During the SSL Handshake, OpenSSL can call a verify_callback
> >>that can manipulate the outcome of the certificate verification
> >>process.
> >>If I use some longterm evaluation like an OCSP-Request, my single
> >>threaded application is blocked during this time. I cannot return
> >>a value like "I don't know yet, ask later" - I have to have the
> >>decision before I return from the callback.
> >>So, there is no change for handling other connections (I usually use
> >>select() and async IO to handle multiple connection which OpenSSL
> >>can do pretty well in all other states...) during that time.
> >>
> >I'm not sure this has ever been tested but it looks like you can handle
> >this by returning -1 from the verify callback instead of the normal
> >1=success or 0=failure. There's some code in place that handles this in
> >a manner analagous to other non-blocking operations using a special
> >condition SSL_ERROR_WANT_X509_LOOKUP.
> >
> Hm, I just tried it, but "-1" accepts the certificate. Maybe I have to
> set something in the X509_STORE which is given as a parameter to the
> verify_callback? I'll have a look into the code, maybe I find something.
The verify_callback() is called inside the X509 verification routines.
At least in the SSL code, the method described must fail, as all certificate
verifications are performed using ssl_cert.c:ssl_verify_cert_chain().
The functions calling it are not prepared to handle return values beyond
"pass" and "fail", see e.g. s3_srvr.c:ssl3_get_client_certificate():
...
i=ssl_verify_cert_chain(s,sk);
if (!i)
{
al=ssl_verify_alarm_type(s->verify_result);
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err;
}
}
...
As you can see the program logic can only distinguish to cases: return
value 0 for failure, 0 for pass. The case "temporary failure" is not
handled, thus the method proposed cannot work. The logic would have
to be extended.
(*) As the check only takes "0" for failure, the "-1" returned must be
understood as "success".
(**) I only checked out the SSL_* routines, but I am also not convinced that
the internal logic in the X509_* verification routines is prepared to
handle temporary failures gracefully.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
