[Pound Mailing List] Whither Close Notify?

Rick Jones <[email protected]>
Newsgroups gmane.comp.web.pound.general
Message-ID <[email protected]>
Hi -

I am very much a noob when it comes to SSL, and have a question 
concerning a Close Notify Alert message.  Doing some web searching 
suggests that at least some of the "commercial" load balancers support 
disabling sending a close notify.  Thusfar I've not seen anything 
similar in Pound.

Just how "according to Hoyle" should one be when it comes to support for 
Close Notify?

I ask because I see a situation where a client out on the Big Bad 
Internet (tm) is connecting through a (stateful) firewall to a service 
over SSL. The service is using Pound to terminate the SSL. The client 
requests something from the service, and the service sends the data. 
When the last bytes of the data arrive at the client, the client does a 
close() on the connection.  All well and good, except the service seems 
to be sending a close notify alert message, which is in flight at the 
time the client closes the connection.

This message hits the client, and since the client called close(), TCP 
issues a ReSeT segment.  Generally speaking, apart from bypassing the 
data integrity protections of TIME_WAIT this is not *that* big a 
deal..., but the firewall in the middle sees the RST and closes-off access.

Meanwhile, the RST segment gets lost somewhere in the Big Bad Internet 
(tm), and TCP on the Pound server continues to retransmit the TCP 
segment containing the close notify.  These hit the firewall, which 
discards them and logs a "DENY" message.

Again, probably all well and good, except the owner of the firewall is 
particularly attentive to those log entries and is rather determined to 
see them go away.

So, the question - convince Pound to make sure that no close notify is 
sent, or convince the client side to make sure it waits for a possible 
close notify to arrive?

thanks,

rick jones
http://www.netperf.org/

--
To unsubscribe send an email with subject unsubscribe to [email protected]
Please contact [email protected] for questions.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.