On Fri, 8 Dec 2000, Jackie Chan wrote:
> >From what I can see it is impossible to create a client and server
> interaction that allows the following behavior using Net::SSLeay
>
> client sends data to the server
>
> server handles data
>
> server waits for more data from the same client over the same connection
>
> Pay close attention to that last line, it seems the only way to get
> write() to hangup is to send a shutdown $socket, 1;
I don't do Perl and this is a Perl issue. That's not a great start for a
response is it ... oh well. This sort of issue is the same no matter what
the application or protocol (or language). What is to stop someone from
initiating attacks on telnet, ftp, ssh, pop3, smtp, http, https, or any
other server protocol in the same way? Such attacks could be by just
opening loads of connections over time but never "completing" any of them,
or just by continuing to hold them open through whatever mechanisms
required (eg. holding open FTP connections from timing out by periodically
trickling a "dir" command through). This has to be handled in the code
that deals with the "real-time" ... namely the application, or network
framework - or in short, wherever it is that chooses when and how to do
reads and writes.
That still doesn't, in itself, solve your problem - but I'm getting there
hopefully. The techniques are many, but the standard ones are non-blocking
IO, timers, connection limits, and so on. non-blocking IO is, of course,
non blocking. I have no idea how that fits into the Perl scheme of things
(let alone Net::SSLeay itself) but I would be highly surprised if there
isn't transparent support for such things. OpenSSL itself (specifically
the socket BIOs and the SSL state machine) have implicit support for
non-blocking IO so you should be able to utilise that somehow from the
Perl wrapper. Another technique of course is to use some kind of timer
whereby you interrupt yourself (or get another process to do it perhaps)
with a signal or whatever your platform/language's support for such a
concept is called (life in Windows might or can be "different"). All the
standard POSIXy (or BSD perhaps) IO functions return from any blocking
calls when a non-blocked signal is received. I'd assume that is (or at
least *can be*) observed from inside the Perl world too so that's one way
to go. Connection limits are probably not what you're after but are the
perfect solution for some other use-cases, eg. telnet, ftp, etc -
protocols where having connections open indefinitely is sometimes
*desirable*, so you control the number of connections rather than
controlling how long they live.
> I have tried to use write_CRLF() and read_CRLF() but they do not act as
> described. If anyone actually HAS done this, I would be most pleased to
> see an example, or even what the respective calls are on either side of
> the connection.
I don't know if your problem here will be with standard DoS logic or the
fact that the Net::SSLeay API itself is being unyielding. If it's the
former - *any* server written in Perl that claims to not be trivial to
attack, stall, or bury would be a good place to look first (eg.
interrupting blocking IO functions, setting connections to non-blocking
mode, doing signal stuff, etc). If it's the latter - I hope you find what
you're looking for.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
