On Tue, Apr 20, 1999 at 11:51:48AM +1000, Clifford Heath wrote:
>> You won't get non-blocking behaviour... The SSL 2 version... The selet()
>> result is valid only for the first iteration, the second interation
>> may block despite of what select() said.
> I'm aware of these behaviours, but we aren't seeing blocking. It's very
> evident when it does block, because the same thread is running both a GUI
> and an Internet SSL connection. The only explanation is that when an SSL
> message is sent, it *all* gets through or none (which means that perhaps,
> sometimes, it actually does block until TCP fixes up the lost fragments,
> but this blocking isn't "noticable").
Sure. If you don't have to worry about denial-of-service attacks
(which almost certainly would be the case e.g. if you handled multiple
concurrent connections with different peers in the same thread), this
can be O.K. The process will block occasionally (unless no SSL record
spans across multiple TCP segments), but only for a short time.
> We're using SSL3 (never 2), and although the protocol has some
> synchronisation, it is fully peer-peer (application-level messages
> can be initiated on a quiescent link by either party).
If these messages are small enough not to fill up the combined TCP
buffers of the two sites, again this is no problem. If messages could
get very large, you might see a deadlock when both processes start
writing at the same time and no-one takes the other partner's data.
>>> && LastError() != WOULDBLOCK)
>> I don't think you'll ever see EWOULDBLOCK if you aren't using
>> non-blocking sockets. BIO_should_retry can only mean EINTR in the
>> situation that you described.
> Interesting. The EWOULDBLOCK test wasn't needed with SSLeay-0.6.6, but
> definitely is needed with 0.8.1.
Really? I'd think that EWOULDBLOCK can happen only if O_NDELAY or
O_NONBLOCK or FIONBIO has been set; could this be another Windows
special?
>> Sorry. Either you have code that accepts blocking (because the
>> application protocol you're running on top of SSL is sufficiently
>> synchronized, e.g. HTTP where there can't be disagreement between both
>> parties where a request ends, amd you don't have to multiplex for
>> various concurrent connections), or you'll have to use non-blocking
>> I/O.
> Neither of these is entirely true. Perhaps loss of part of an SSL packet
> does cause blocking, but not for so long (before TCP fixes it) that the
> effect on the GUI is noticable. So the method I've describe does work,
> and may in fact be suitable for other applications. The only reason I
> wrote is because I'd like the method to continue "working" as well as it
> does.
>> And if SSL 3 or TLS is used, things become more compliated, as
>> there's always the possibility that a new handshake is started.
> Not in this case I think, because we control both ends and don't renegotiate.
O.K. If the use of the SSL protocol is restricted in a way that lets
your "semi-blocking" approach for reading work, then, well, that
approach will work; still one has to keep in mind that it may fail
when it comes to interoperating with other software, and that an
active attacker can freeze the SSL_read.
But I really wouldn't think that the change that I proposed will break
anything. In fact, the current code breaks s_client and s_server.
The modification would change behaviour only for the case that the
sender sends an SSL 2 record that contains no payload data at all, and
I bet your program never does that (similar to its never attempting
renegotiation); and if it did, quite possibly the receiver would
incorrectly interpret this as EOF and close the connection, which is
what s_client and s_server would do.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
