Geoff,
Thank you very much. As for the possible attack scenario, i
negelected to mention that there would be a 5 second delay after
connection, then a challenge response. After that I am hoping to have the
read on the server side blocking, and the write on the client side, non
blocking.
I will definately look a little closer at the documentation for
Net::SSLeay to see how to access these characteristics of OpenSSL.
I was hopijng to stay away from alarms and such, just to make the code a
little cleaner, but you are right, I may have to resort to such an avenue,
but msot likely that will indicate that I failed to figure out my original
problem. I do not have this poroblem using normal sockets, it is only
wiht the Net::SSLeay modules that this seems to plague me. It may be that
the other modules I use make these autoflush by default, and the FD that
Net::SSLeay is using is not. I think I just answered my question.
Either way, thank you very much for your tactful, and insightful response.
-blue0ne
http://www.digitz.org
"That ideas should spread from one to another over the globe, for the moral and
mutual instruction of man, and improvement of his condition, seems to have been
peculiarly and benevolently designed by nature, when she made them , like fire,
expansible over all space, without lessening their density at any point, and
like the air in which we breathe, move, and have our physical being, incapable
of confinement or exclusive appropriation. Inventions then cannot, in nature,
be a subject of property."
- Thomas Jefferson
On Fri, 8 Dec 2000, Geoff Thorpe wrote:
> 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]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
