Wireshark · Wireshark-users: Re: [Wireshark-users] ***UNCHECKED*** SSL/TCP Connection termination results in RST

["Chandler, Mel" <Mel.Chandler@xxxxxxx>]

Sake,

 

Thanks for the response, sorry for the late reply.  That's how I see it working as in Case 1, where the VeriFone terminal sends its FIN, and I see an encrypted Alert come back from the server as part of the server's FIN, after it attempts to resend it's final PSH several times, but I don't know if the encrypted alert is an error condition or a close_notify as you stated below.  I'm not sure if the actual alert is encrypted.  Is there a way to see what the encrypted alert is if you don't have the private key?  I think it would be impossible to get the private key from TSys.  It said it was message Type 21, which I believe is decryption/failed, but for TLS.  This is SSL.  I think the problem may be that the client is not closing the SSL session prior to closing the TCP session.  The server after numerous attempts finally closes the SSL session and the TCP session all at once. 

 

I didn't encrypt the zip file so that's odd you're having problems uncompressing it.  I'll see if it lets me attach the pcap's.  Thanks again.

 

Chandler Bing

 

From: Sake Blok <sake@xxxxxxxxxx>
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.

 

   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

 

 

 

 

Mel L. Chandler

Yum! Brands, Inc.
Network Engineering & Projects Team
17901 Von Karman Ave, MD602
Irvine, CA 92614-6297
+ E-Mail  mel.chandler@xxxxxxx
( Office   +1 949-863-3830
2 Fax  +1 949-863-4507
; Pager  5622763375@xxxxxxxxxxx

 

 

DISCLAIMER:
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.

Attachment: 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

Attachment: QA POS Lab - HNS DSL - SSL - Re-Trans - RST ACK.pcap
Description: QA POS Lab - HNS DSL - SSL - Re-Trans - RST ACK.pcap

Attachment: QA POS Lab - ISS DSL - Re-Trans - RST ACK.pcap
Description: QA POS Lab - ISS DSL - Re-Trans - RST ACK.pcap

Attachment: QA POS Lab - VSAT - SSL - Spoofing disabled.pcap
Description: QA POS Lab - VSAT - SSL - Spoofing disabled.pcap