On Mon, 2013-06-03 at 15:07 -0700, Rick Jones wrote: > 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?
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. - the TCP stack (not Pound) attempts several retries. This is normal behaviour and works as expected. 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. -- Robert Segall Apsis GmbH Postfach, Uetikon am See, CH-8707 Tel: +41-32-512 30 19 -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
