Wireshark-users: Re: [Wireshark-users] ***UNCHECKED*** SSL/TCP Connection termination results in
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.
close_notify
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...
Cheers,
Sake
