Wireshark-users: Re: [Wireshark-users] ***UNCHECKED*** SSL/TCP Connection termination results in
From: Sake Blok <[email protected]>
Date: Fri, 6 Jun 2008 00:55:14 +0200
On Thu, Jun 05, 2008 at 12:17:45PM -0700, Chandler, Mel wrote:
> My company is working with VeriFone and TSys to isolate issues we've
> seen with SSL transactions. We're being told that once one side sends a
> FIN, that terminates the entire conversation and indeed the other side
> still has data to send and when it performs a PSH, it's ignored and
> ultimately the connection is RST. I'm being told by both sides that this
> is normal. I don't believe it is. 

<From RFC 793 - Transmission Control Protocol>

  Case 1:  Local user initiates the close

    In this case, a FIN segment can be constructed and placed on the
    outgoing segment queue.  No further SENDs from the user will be
    accepted by the TCP, and it enters the FIN-WAIT-1 state.  RECEIVEs
    are allowed in this state.  All segments preceding and including FIN
    will be retransmitted until acknowledged.  When the other TCP has
    both acknowledged the FIN and sent a FIN of its own, the first TCP
    can ACK this FIN.  Note that a TCP receiving a FIN will ACK but not
    send its own FIN until its user has CLOSED the connection also.

  Case 2:  TCP receives a FIN from the network

    If an unsolicited FIN arrives from the network, the receiving TCP
    can ACK it and tell the user that the connection is closing.  The
    user will respond with a CLOSE, upon which the TCP can send a FIN to
    the other TCP after sending any remaining data.  The TCP then waits
    until its own FIN is acknowledged whereupon it deletes the
    connection.  If an ACK is not forthcoming, after the user timeout
    the connection is aborted and the user is told.

</From RFC 793 - Transmission Control Protocol>

The remaining data that is sent should not be ignored by the TCP stack
and should be ACKnowledged. However...

<From RFC 2246 - The TLS Protocol>

7.2.1. Closure alerts

   The client and the server must share knowledge that the connection is
   ending in order to avoid a truncation attack. Either party may
   initiate the exchange of closing messages.

       This message notifies the recipient that the sender will not send
       any more messages on this connection. The session becomes
       unresumable if any connection is terminated without proper
       close_notify messages with level equal to warning.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Each party is required to send a close_notify alert before closing
   the write side of the connection. It is required that the other party
   respond with a close_notify alert of its own and close down the
   connection immediately, discarding any pending writes. It is not
   required for the initiator of the close to wait for the responding
   close_notify alert before closing the read side of the connection.

   NB: It is assumed that closing a connection reliably delivers
       pending data before destroying the transport.

</From RFC 2246 - The TLS Protocol>

My interpretation is that once a host receives an ssl close_notify,
it should issue a close_notify itself, which will be queued after the
pending data at the transport layer. But this host should not accept any 
more data from it's application layer. But that's my interpretation :-)

> I have packet captures, but I'm not sure how to post them or share them
> out. 

Well, the zipfile seems to be password protected...