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.
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.
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.
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>
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.
Any data received after a closure alert is ignored.
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.
pending data before destroying the transport.
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 :-)
Mel L. Chandler
This communication is confidential and may be legally privileged. If you are not the intended recipient, (i) please do not read or disclose to others, (ii) please notify the sender by reply mail, and (iii) please delete this communication from your system. Failure to follow this process may be unlawful. Thank you for your cooperation.
QA POS Lab - VSAT - SSL - Spoofing enabled - Re-Trans - RST ACK.pcap
Description: QA POS Lab - VSAT - SSL - Spoofing enabled - Re-Trans - RST ACK.pcap
QA POS Lab - HNS DSL - SSL - Re-Trans - RST ACK.pcap
Description: QA POS Lab - HNS DSL - SSL - Re-Trans - RST ACK.pcap
QA POS Lab - ISS DSL - Re-Trans - RST ACK.pcap
Description: QA POS Lab - ISS DSL - Re-Trans - RST ACK.pcap
QA POS Lab - VSAT - SSL - Spoofing disabled.pcap
Description: QA POS Lab - VSAT - SSL - Spoofing disabled.pcap