Jeroen Wortelboer wrote:
>
> Hi there,
> is it possible to split the SSL_accept and SSL_connect functions into
> several others that do not block ?
>
> I would like to have an alternative for SSL_accept that would allow me
> to regain control inbetween the SSL handshake frames. I would like to
> wait for each next frame of the handshake with a select statement and
> still be able to react to other concurrent sessions.
>
> Is this possible ?
>
> I have been thinking about selecting inside the info_callback but it
> won't solve the problem. (and is ugly)
>
We are doing some thing similar. We are working on a GSSAPI
implementation
on top of SSL, using the SSL handshake for the authentication. GSS
authentication
requires the application to loop over calls to gss_init_sec_context in
the
client, and gss_accept_sec_context on the server. The application
sends and receives the tokens generated by these gss routines.
To convert the SSL handshake to the tokens, we used a BIO_s_mem for the
read
and write BIOs with the ssl BIO. When the client routine blocks on read,
we take
what it has written convert this to a token, and pass it back, it gets
sent to the server, added to the servers read BIO and the server side
of the handshake is started. When the server blocks on read, we repeat
the process send the return token back to the client. This continues
till
the handshake completes.
You could do something similar by adding your own non blocking BIO
to the read and write BIOs for the ssl. See the BIO_should_retry
routine.
> thanks !
>
> Jeroen.
> +-------------------------------------------------------------------------+
> | Administrative requests should be sent to [EMAIL PROTECTED] |
> | List service provided by Open Software Associates, http://www.osa.com/ |
> +-------------------------------------------------------------------------+
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
