Re: [Pound Mailing List] Whither Close Notify?

On 06/04/2013 03:39 AM, Conor McCarthy wrote:
> On 3 June 2013 23:07, Rick Jones <[email protected]> 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.
>
>
>>From http://www.openssl.org/docs/ssl/SSL_shutdown.html
>
>      The shutdown procedure consists of 2 steps: the sending of the
> ``close notify''
>      shutdown alert and the reception of the peer's ``close notify''
> shutdown alert.
>
>      According to the TLS standard, it is acceptable for an application
> to only send
>      its shutdown alert and then close the underlying connection without waiting
>      for  the peer's response (this way resources can be saved, as the process
>      can already terminate or serve another connection). When the underlying
>      connection shall be used for more communications, the complete shutdown
>      procedure (bidirectional ``close notify'' alerts) must be
> performed, so that the
>      peers stay synchronized.

So, the first part suggests the "most correct" thing to do is for the 
two peers to exchange close notify messages - send a close notify, wait 
to receive a close notify, close the connection yes?

But that second bit - allowing an application to send a close notify and 
close is then setting things up for the very TCP RST situation described 
in my initial message.  Unless I'm missing something of course. One side 
sends a close notify and calls close().  The other side receives it, 
sends its own close notify, and bam, TCP RST (which may well be lost), 
followed by retransmissions of the TCP segments carrying the second 
close notify message.

Similarly for simultaneous closes by the peers though without the 
retransmissions.  Each close notify message will find a close()ed TCP 
endpoint, triggering a RST in each direction and no more transmissions.

Unless it was supposed to be assumed that the client would do:

shutdown(SHUT_WR)
<wait via some means for the read return of zero indicating peer TCP FIN 
arrived>
close()

but in terms of time and calls, that would be no different really from 
waiting for a close notify from the peer.  In fact, if I've understood 
the above correctly, the client would end-up "draining" a peer close 
notify message in the process of getting to the read return of zero on 
the socket.

>>
>> 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.
>
>
> The client SSL behaviour is not correct, badly implemented clients are
> common, and unavoidable. See RFC2246 §7.2.1. close_notify alerts are
> not optional (see the retrospective RFC6101 §5.4.1 for SSLv3).
>
> If it's really just calling close(), then it's doing it wrong, hence
> the RST.. TCP handshaking and application handshaking are not the same thing.

Though they end-up interacting, per the above.  It would seem there 
needs to be two flavors of close notify?  One that says I'm closing the 
session but continuing the TCP connection, and another that says I'm 
going away completely - thus informing the peer it should not send a 
close notify of its own.

> The in-protocol shutdown was added in SSLv3.0 to provide detection and
> mitigation for truncation and connection close attacks (an issue in SSL2.0),
> so not properly supporting this  may have some effect on the security of
> connections.
>
>>
>> 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.
>
>
> "out of state" packet drops, also unavoidable.
>
> There are no calls to "SSL_CTX_set_quiet_shutdown()" in the Pound source,
> so you would need to patch it to add this. There are possibly some
> subtleties around the use of blocking or non-blocking I/O and calling
> SSL_shutdown() twice. The shutdown in Pound is done via the "clean_all"
> macro, it only calls one shutdown, and does not check the return code to
> see if a second is required. Perhaps someone here who's more familiar
> with the code could help fill in some details.
>
>> 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?
>
>
> The pragmatic approach might be to convince the other party  that there will
> always be a level of noise logged when dealing with unknown (and poorly
> written) clients.
>
> Since the client is clearly out of spec, fixing that is the idealist
> approach ;-)

Idealism.  I remember that :)  Are there "known, in-spec" SSL/TLS 
clients out there?

rick jones

>
> C.
>
> --
> To unsubscribe send an email with subject unsubscribe to [email protected].
> Please contact [email protected] for questions.
>


--
To unsubscribe send an email with subject unsubscribe to [email protected]
Please contact [email protected] for questions.