non-blocking SSL_Accept.
James A. Russo
I am working on an event driven (non-blocking) SSL proxy, but am
experiencing a problem with SSL_accept on some connections.
The connection is accepted, and SSL_accept is called. It normally takes a
few calls to SSL_accept (with some returning WANT_*) in order for the SSL
connection to be established. This is fine. However, sometimes the
connection is never accepted and the SSL_Accept constantly returns
WANT_READ and doesn't go anywhere.
Is there any way I can find out what stage/state the accept is in? I could
then use this information to better find out what is going on.
Like I said this only happens occasionally and normally only under load.
any help is appreciated.
-jr
--
James A. Russo
Systems Engineer
Verio, Inc.
jru...@verio.net
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Lutz Jaenicke
> I am working on an event driven (non-blocking) SSL proxy, but am
> experiencing a problem with SSL_accept on some connections.
>
> The connection is accepted, and SSL_accept is called. It normally takes a
> few calls to SSL_accept (with some returning WANT_*) in order for the SSL
> connection to be established. This is fine. However, sometimes the
> connection is never accepted and the SSL_Accept constantly returns
> WANT_READ and doesn't go anywhere.
>
> Is there any way I can find out what stage/state the accept is in? I could
> then use this information to better find out what is going on.
Have a look into the "info_callback" part in openssl/apps/s_cb.c and s_server.c.
I didn't find the time to write the manual pages, yet.
You may also consider using www.rtfm.com/ssldump to assist you in tracking
it down...
Best regards,
Lutz
--
Lutz Jaenicke Lutz.J...@aet.TU-Cottbus.DE
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
James A. Russo
Lutz -- Thanks for your suggestion, it has allowed to get a little bit
further, but am still not sure what is going on.
Here is the information from the callback and my application.
Slot 0x80e7800: assigned to new connection from ip:port on fd 18
slot 0x80e7800: RCONN_SSL_ACCEPTING
slot 0x80e7800: SSL_accept:before/accept initialization
slot 0x80e7800: SSL_accept:SSLv3 read client hello A
slot 0x80e7800: SSL_accept:SSLv3 write server hello A
slot 0x80e7800: SSL_accept:SSLv3 write certificate A
slot 0x80e7800: SSL_accept:SSLv3 write key exchange A
slot 0x80e7800: SSL_accept:SSLv3 write server done A
slot 0x80e7800: SSL_accept:SSLv3 flush data
slot 0x80e7800: SSL_accept:error in SSLv3 read client certificate A
slot 0x80e7800: SSL_accept:error in SSLv3 read client certificate A
slot 0x80e7800: SSL_ACCEPT wants to read more
slot 0x80e7800: RCONN_SSL_ACCEPTING
slot 0x80e7800: SSL_accept:error in SSLv3 read client certificate A
slot 0x80e7800: SSL_ACCEPT wants to read more
slot 0x80e7800: RCONN_SSL_ACCEPTING
slot 0x80e7800: SSL_accept:error in SSLv3 read client certificate A
slot 0x80e7800: SSL_ACCEPT wants to read more
slot 0x80e7800: RCONN_SSL_ACCEPTING
Seem like the server is reading the hello, writing back all it's
information but then never hearing anything again.
Why would the server want to read the client certificate if we are not
doing client authentication?
Thanks for any insight.
-jr
On Wed, 22 Aug 2001, Lutz Jaenicke wrote:
> On Wed, Aug 22, 2001 at 06:52:33PM -0400, James A. Russo wrote: > I am
> working on an event driven (non-blocking) SSL proxy, but am >
> experiencing a problem with SSL_accept on some connections. > > The
> connection is accepted, and SSL_accept is called. It normally takes a
> > few calls to SSL_accept (with some returning WANT_*) in order for
> the SSL > connection to be established. This is fine. However,
> sometimes the > connection is never accepted and the SSL_Accept
> constantly returns > WANT_READ and doesn't go anywhere. > > Is there
> any way I can find out what stage/state the accept is in? I could >
> then use this information to better find out what is going on.
>
> Have a look into the "info_callback" part in openssl/apps/s_cb.c and s_server.c.
> I didn't find the time to write the manual pages, yet.
>
> You may also consider using www.rtfm.com/ssldump to assist you in tracking
> it down...
>
> Best regards,
> Lutz
>
--
James A. Russo
Systems Engineer
Verio, Inc.
jru...@verio.net
______________________________________________________________________
Lutz Jaenicke
Don't care. The client will continue with the next part of the handshake
and the server will note that no client certificate was sent and will
also continue with the next step.
Now back to your problem: From the output it clearly seems, that SSL_accept()
is waiting for more input from the peer.
I don't know enough about your underlying implementation. Normally
slot 0x80e7800: SSL_accept:SSLv3 flush data
should make sure that the SSL-internal write buffer is flushed _and_ that
the data is flushed down all the way to the peer. If that does not happen,
the peer does not get the "server done A" message and itself is sitting
and waiting. I had this effect with BIO-pairs, where the data to be written
to the client was simply written to the buffer, but I had to make sure
that all data is sent to the client to avoid this deadlock.
You should not have any problems in this respect when using the normal
socket BIOs.
We now need to be sure, that the client did receive the "server done".
* If you have control over the client, you should be able to check out
its state.
* If you don't have control over the client, you may consider using "ssldump".
You may see by far more data than you want. You should however be able
to insulate the offending connection, because it stays open...
* There is another option in setting up a "dump_cb" for the BIO layer.
You can find an example in s_server.c/s_cb.c. It should show you the
data passing the BIO. Actually, ssldump does fetch this data from the
net and then analyses it for you...
* You may also consider using trace/tusc/truss or whatever the system call
tracer on your platform is called. I however would think that it won't
be easy to analyze the output looking for "write()" operations and
find out whether really everything was written...
I would say, that the combined "check client state"/"ssldump"
approach sounds most promising.
Best regards,
Lutz
--
Lutz Jaenicke Lutz.J...@aet.TU-Cottbus.DE
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153