Michael Shanzer <[EMAIL PROTECTED]> writes:
> [1 <text/plain; us-ascii (7bit)>]
>
> --- Greg Stark <[EMAIL PROTECTED]> wrote:
> > It would be easier to help you if you can get output
> > from ssldump
> > (www.rtfm.com/ssldump) for the failing connection
> > attempt.
> Attached is the output of ssldump.
> Since I can not get the keys out of IIS All the data
> is still encrypted. Thanks for anyhelp!
Ok. There appear to be two things happening here:
(1) The client is sending an alert. Without the keying
material I can't tell what it is.
(2) You're getting an error from SSL_read(). Now,
in practice, this is an error from the handshake,
which is being performed automatically by SSL_read().
These may be related but the fact that the handshake
continues after the alert suggests otherwise. I'd be
interested to see what the alert is if you ever get the
handshake decrypted.
You need to see what the error being returned by SSL_read()
is. It's quite possible that it's SSL_ERROR_WANT_READ.
Here's an excerpt from the appropriate section of my upcoming
Linux Journal article:
Automatic rehandshake support is built into SSL_read(), so
the client doesn't have to do anything explicit to enable
rehandshake. However, this doesn't necessarily mean that
arbitrary clients will work. In particular, the client must
be prepared to handle the SSL_ERROR_WANT_READ return value
from SSL_read(). Ordinarily, if the client is using blocking
I/O --as we are in wclient2-- SSL_read() would never return
this error. However, it's required if rehandshaking occurs.
To see why this is, imagine that your client uses select()
to determine when there is data available from the server.
When select() returns is you call SSL_read(). However, if
the server is requesting rehandshake the data will be a Hel-
loRequest message. SSL_read() consumes the message and per-
forms the handshake. There's no guarantee that there will be
any more data available on the socket so SSL_read() needs to
return without any data--hence the SSL_ERROR_WANT_READ
return value.
This almost certainly isn't a select() race condition of the type
described by Greg, since you're using blocking I/O. Rather, it's just
a simple case of confusing OpenSSL semantics.
I'm not sure why you're using select() here at all. I assume
that you eventually intend to have some sort of multiplexed I/O.
If so, it's a really bad idea to use select() with OpenSSL and
blocking I/O. If the record arrives in pieces and you have
network congestion, it's quite likely your application will
hang reading a partial record.
OTOH, if you were using non-blocking I/O you'd need to be willing
to handle SSL_ERROR_WANT_READ anyway.
-Ekr
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
