On 06/05/2013 06:45 AM, Robert Segall wrote:
I suspect you see here two issues, which are quite separate, and should
not be mixed:
- the client does a close without an SSL shutdown. Should not happen,
but it does quite often.
I will push on the client. Are there "known to be correct" SSL client
libraries at which I can point people?
- the TCP stack (not Pound) attempts several retries. This is normal
behaviour and works as expected.
Agreed.
I think the most pragmatic fix is to make sure the firewall passes the
RST packet to the Pound machine (which I suspect it does not). This will
ensure that no retries are attempted and your firewall log should stay
clean.
I would hope the firewall is passing the RST. However, since the Big
Bad Internet (tm) sits between the client+firewall and the service,
there is a (perhaps small but) measurable probability that the RST will
be lost somewhere along the way. At that point, unless the firewall
generates RSTs on its own, the as expected retransmissions of the
service's close notify messages will continue.
One question that has been at the back of my mind, one that may sit
between SSL and TCP. What *should* a server do if the TCP connection is
closed (ie the server code or library it calls) gets a read return of
zero) before an SSL Close Notify is received on the TCP connection?
Should it go ahead and send a Close Notify of its own, or should it
(being pragmatic I suppose?) assume the client isn't waiting around for
a Close Notify anyway and just go ahead and close() the TCP connection?
(And optionally log a Nasty Message (tm) calling-out the IP address/name
of the client as misbehaving)
rick
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
