On Thu, Aug 23, 2001 at 05:45:55PM -0400, James A. Russo wrote:
> 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?
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 [EMAIL PROTECTED]
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
