[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: Stunnel 3.2
From:       Bodo Moeller <3moeller () informatik ! uni-hamburg ! de>
Date:       1999-04-29 13:36:42
[Download RAW message or body]

On Thu, Apr 29, 1999 at 10:00:17AM +0200, Michal Trojnara wrote:

>> I think your program will likely get stuck when the peer starts a
>> renegotiation, as you don't obey SSL_ERROR_WANT_WRITE
>> and SSL_ERROR_WANT_READ.

> I do (I hope).  According to documentation I should restart
> select on WANT_WRITE and WANT_READ.  This is exactly
> what I do.  Where am I wrong?

The point is that when you see ..._WANT_WRITE, you have to select for
writeability, and obviously when you see .._WANT_READ, you have to
select for readability.  SSL_write may want to read from the network
connection, and SSL_read may want to write to it.  I think stunnel.c
selects for writeability when it wants to do SSL_write and for
readability when it wants to do SSL_read.

The difficult part of this is that if you both want to read and to
write, then both SSL_read and SSL_write may return -1 with
..._WANT_..., and you don't know if the result of the first call is
still valid after the second one -- if the second call managed to do
some of its network I/O, then the return status of the first call may
have becomed invalild.  But if you repeat the first call after the
second one, the result of the second one may no longer be valid, etc.
So I look at BIO_num_read and BIO_num_written to observe if something
happened.

Another fine point is that before the select, if you want to read, you
should test SSL_pending.  (Maybe you even do, I'm too lazy to check.)
s_client used to have a bug related to this.


>> for the case where lingertime is 0. -- It works fine on Solaris.

> It works fine even on Win32.  Well...  It's a BSD sockets
> standard, so it should be implemented [...]

Yes.  It's a Linux problem, and it cost me some time when I couldn't
determine why I didn't get the error messages that I expected.

>> 1024 bit temporary keys are defined only in certain new,
>> experimental ciphersuites that Netscape doesn't have yet.

> Looks like Microsoft is sometimes better then Netscape.  8-(

Have they implemented those ciphers by now in public releases of
Internet Explorer?  When I last looked at IE5, there were only the
known ciphers.  Maybe they accept too long keys for those?

But at least if you are using a callback for temporary RSA keys (I'm
not sure how things are if you set the keys directly), you can provide
keys of both key.  The callback function has an argument that tells it
how large the key may be.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org

[prev in list] [next in list] [prev in thread] [next in thread]