Tim Regovich <[EMAIL PROTECTED]> writes:
> One point that I thought was implicit in my comment
> when I started was that the timeout approach using
> some sort of alarm around a call to say SSL_accept, is
> that you cannot use the TCP timeouts, because
> SSL_accept wraps a whole serious of TCP transactions.
Well, you first need to decide what your timeout strategy *IS*.
In many cases you want multiple timeouts, one per "activity" and one
master timeout. So, you might say "don't let any given TCP write take
more than 15 seconds and don't spend more than 5 minutes on any
clients".
> My assertion is that given a situation where TCP
> transactions as taking place, it is difficult to come
> up with a reasonable timeout number.
That's always the case. Nonblocking I/O doesn't make it
much easier.
> Using non blocking I/O with OpenSSL is no more or less
> tricky than using non blocking I/O for any other
> application,
I'm sorry, but this isn't true. Using non-blocking I/O with OpenSSL is
rather more complicated than using it with straight sockets. More
importantly, just translating sockets idioms to OpenSSL leads to
problems. The basic issue is that the SSL record structure doesn't
match the way that the data is put on the wire. Thus, (for instance),
with ordinary sockets it's safe to do:
while(select(socket)){
read(socket,buf);
write(socket,buf);
}
There are also difficulties with writing.
This can easily lead to deadlock with OpenSSL because there might
still be data in the SSL buffers but not on the network socket.
These issues are discussed quite extensively in "SSL and TLS" as well as
in my "Introduction to OpenSSL Programming", available at
http://www.rtfm.com/openssl-examples
-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]
