Thor Lancelot Simon wrote:

>       1) I have data to write, and the SSL session's descriptor
>          selects as ready-to-write.

This already scares me. You have data to write on the unencrypted stream to
the SSL connection. The SSL session's descriptor write is for the encrypted
stream between SSL implementations. Why would you check one when you want to
write to the other?

You should only be calling 'select' to see if a descriptor is ready-to-write
if you know you need to write on that descriptor. Since SSL_write did not
return 'WANT_WRITE', you had no way to know OpenSSL needed to write on the
socket.

>       2) I call SSL_renegotiate.  I do understand that in a server
>          application this merely sends the client a request to
>          do a new handshake, which the client can ignore.
>
>       3) I generate more data and several more SSL_writes() complete
>          normally.
>
>       4) Eventualy the SSL session's file descriptor selects as
>          ready-to-read.

Did an SSL_read return WANT_READ? If not, why were you selecting on the file
descriptor for read?

What you are doing makes failure scenarios possible. Consider:

1) You call SSL_write. Since a renegotiation is in progress, it tries to
read the data to complete the rengotiation.

2) It reads the renegotiation data, and some application data. It completes
the write.

3) You select on the socket for 'read', but you don't get a hit because the
data has already been read.

So why were you waiting for the SSL session's file descriptor to select as
ready-to-read?

An SSL connection has *ONE* *STATE*. When SSL_write completes normally, its
state is "everything is fine". It's state is *NOT* "want read", which seems
to be what you were assuming.

>       5) I call SSL_read with a 4096-byte buffer.  SSL_read returns
>          -1 and error is SSL_ERROR_WANT_READ.

So now you know that a read hit from select is needed (or other forward
progress must be made) before SSL_read can succeed.

>       6) I set a flag to ensure I do not call SSL_write() (it isn't
>          clear to me this is necessary -- the documentation is vague)
>          and select on the SSL session's descriptor for read.

Why would you avoid writing? It's possible the other side will not send any
application data.

>       7) The SSL session's file descriptor selects as ready for read,
>          I call SSL with the same 4096 byte buffer at the same address,
>          and SSL_read returns -1 and error is SSL_ERROR_SSL.
>
> I cannot understand why #7 occurs.  Is SSL_MODE_ENABLE_PARTIAL_WRITE just
> incompatible with non-blocking mode and renegotiations?

Perhaps the other side gave up waiting for you and closed the connection
down abruptly? What does the other side show when this happens?

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to