SSL/TCP Connection termination results in RST

Discussion in 'Cisco' started by Chandler Bing, Jun 5, 2008.

  1. 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.

    I have packet captures, but I'm not sure how to post them or share
    them out.
     
    Chandler Bing, Jun 5, 2008
    #1
    1. Advertisements

  2. Chandler Bing

    News Reader Guest

    My belief is as follows:

    A TCP connection is duplex; with an independent stream in each
    direction. When one side has no more data to send it can close its half
    of the duplex connection.

    When a Sender finishes sending its data, it waits for an ACK from the
    Receiver, and then may send a FIN segment to close its half of the
    connection. The Receiver would ACK the FIN segment, and inform the local
    application that no more data will be forthcoming. The Receiver would
    not respond immediately with a FIN segment, but would instead wait for a
    response from the local application. Prior to receiving a response from
    the local application, data should be able to flow on the non-closed
    side of the duplex connection, if there is data to send.

    When the local application responds with the authorization to shutdown
    the 2nd half of the duplex connection, a FIN segment is sent to the
    other side. That FIN segment will be ACK'd ending the four-way handshake.

    I think a RST is used to close/abort transfers in both directions, and
    occurs under abnormal conditions.

    That's about all I can offer.

    Best Regards,
    News Reader
     
    News Reader, Jun 6, 2008
    #2
    1. Advertisements

  3. So any good advice that would tell the vendor to STFU?

    Chandler Bing
     
    Chandler Bing, Jun 9, 2008
    #3
  4. Chandler Bing

    noah davids Guest

    I've seen this behavior before. What I saw was that the side sending the FIN
    is not waiting for the other side to respond, it is just closing the socket
    and terminating the process. The OS then cleans up the socket structures.
    When the OS gets a packet for that connection it no longer has any place to
    send it and so responds with an RST.

    Basically, it is an application error and needs to be corrected in the
    application. Either the application should not close the connection until it
    is sure that the remote side is done sending data (some kind of indication
    at the application protocol layer) or it should call shutdown, indicating
    that it is done sending data and then loop receiving data until it gets an
    indictaion that the remote side has sent a FIN. Then it can close the socket
    and terminate the process.


    So any good advice that would tell the vendor to STFU?

    Chandler Bing
     
    noah davids, Jun 10, 2008
    #4
  5. As I look more at the traces, it appears the VeriFone terminal
    (client) does a TCP close. It does not do an SSL close_notify, as it
    should. The server attempts to push some final TCP data, but is
    ignored, it finally does its own encrypted alert, which is message
    type 21. I'm not sure, but I think that's decryption_failed, but that
    doesn't seem right, since it's a TLS message and this is SSL. After
    numerous attempts it finally does a close_notify & FIN which prompts
    the VeriFone terminal to do a RST.

    It appears that the VeriFone terminal is doing a TCP close, without
    closing the SSL session and then doesn't allow the other side to close
    it's TCP session. I've since found out that the VeriFone terminal
    runs a firewall made by McAfee. I wonder if it's their application,
    IP Stack, or firewall that's causing all these problems.

    Chandler Bing


     
    Chandler Bing, Jun 16, 2008
    #5
  6. Chandler Bing

    Bod43 Guest

     
    Bod43, Jun 17, 2008
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.