Arne Ansper wrote:
>
> > I'd say that has very little to do with BIOs and more to do with the
> > fact that the public key API has no concept of "non blocking operations"
> > and this has filtered down to the SSL API.
> >
> > It may be possible to actually do what you want through some of the SSL
> > state callbacks but I haven't looked at that in much detail. Something
> > like tracking the states and then moving the execution to another thread
> > when the state involve expensive crypto operations then shifting it back
> > when they have finished.
>
> adding support for non-blocking public key operations to SSL handshake
> requires a lot of changes. first, one must add new states to SSL
> statemachine for public key operations. then we need a non-blocking
> interface for public key operations.
>
> right now BIO's are used for all non-blocking data sources (sockets, SSL).
> i think that public key operations should have a BIO interface too.
> then we can add third sub-BIO to SSL statemachine: a public key BIO.
>
Actually there's already something like this for the X509_LOOKUP stuff
in the SSL state machine which simply attaches a "special" reason to the
SSL BIOs or SSL structures. Though AFAIK absolutely nothing uses it.
What this would involve in practice is some callback for public key
operations which is passed the relevant SSL structure then it could
attach some relevant ex_data when it was called. Then whenever the
public key operation was completed it would retry. The default callback
would always block as at present.
> this will make event handling even more complex: right now event handling
> is left to application and everyone must fight with select and
> SSL_get_error. when we add non-blocking public key crypto, then we create
> another source of events.
>
> i think that adding generalized event management into OpenSSL is good
> idea. i have in mind something like BIO_select, which looks like and works
> like a ordinary select, but accepts a set of BIO's instead of file
> handles. BIO_select calls every BIO's statemachine function, which fills
> out FD_SETs for real select function and finally calls a real select
> function with appropriate FD_SETs. timeout management and even signal
> management can be added to this function. under Windows we can
> transparently use Windows-specific event management functions like
> WSAEventSelect and WaitForMultipleObjects to overcome the limitations of
> select.
>
This is actually rather difficult (or impossible) to do cross platform.
You can use select for certain things only and you can have fun with the
Windows variants as well. How to wait for a public key event to finish
is likely to be very hardware/software specific and possibly combining
that with various fd related events is likely to make things harder
still.
Currently we take the easy way out and don't even try any of this and
leave the application to decide what to do.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.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
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
