Re: [Pound Mailing List] Whither Close Notify?

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.