Re: Longterm verify_callback in single threaded app
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. Thanks so far. Jörg __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Longterm verify_callback in single threaded app
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]
Re: Longterm verify_callback in single threaded app
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. Does anybody have a solution? Thanks in advance, 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. Performance is likely to be rather poor managing all connections in one thread because some operations are relatively slow such as private key functions which will occur during the initial handshake. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Longterm verify_callback in single threaded app
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. Does anybody have a solution? Thanks in advance, Joerg P.S.: I thought I had send this email a couple of days ago already, but it did not show up - so I assume, I didn't :-( __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Longterm verify_callback in single threaded app
On Fri, Mar 08, 2002 at 09:42:42AM +0100, Joerg Bartholdt wrote: 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. Does anybody have a solution? Hmm, hmm. Sounds like this case has not been prepared. When asking the user for a client certificate, the case seems to be prepared (look for SSL_X509_LOOKUP in s3_clnt.c). However: as far as I understand, OCSP has only been introduced after the verify_callback() thing was invented, so the case you describe has not been covered. I think it would be possible to enhance libssl to also handle this case, but it would require quite some rewrite of the mechanism... P.S.: I thought I had send this email a couple of days ago already, but it did not show up - so I assume, I didn't :-( I remember reading about it, but I also remember not having an answer at that time. Good luck, 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]
