SSL/TCP Connection termination results in RST - TCP-IP

This is a discussion on SSL/TCP Connection termination results in RST - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: SSL/TCP Connection termination results in RST

  1. SSL/TCP Connection termination results in RST

    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.

  2. Re: SSL/TCP Connection termination results in RST

    In article ,
    Chandler Bing 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 good tool for troubleshooting SSL is curl

    http://curl.haxx.se/

    alan

  3. Re: SSL/TCP Connection termination results in RST

    On Jun 5, 12:00*pm, pale...@sonic.net (Alan Strassberg) wrote:
    > In article ,
    > Chandler Bing * 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 good tool for troubleshooting SSL is curl
    >
    > * * * *http://curl.haxx.se/
    >
    > * * * * * * * * * * * * alan


    Any suggestions as to how?

    Keep in mind the transaction we're monitoring is from a VeriFone
    credit card terminal to TSys' server on the internet. To perform a
    transaction there's a lot of information I'd need from the terminal
    that I just don't have.

    Chandler Bing

  4. Re: SSL/TCP Connection termination results in RST

    Chandler Bing 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.
    >
    > I have packet captures, but I'm not sure how to post them or share
    > them out.


    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

  5. Re: SSL/TCP Connection termination results in RST

    Chandler Bing 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.


    It's correct for SSL. RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt) #7.2.1:

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

    Now the RFC doesn't mandate a strong connection between SSL connections
    and connections of the underlying transport, so in theory close_notify
    != FIN, but, in practice, SSL APIs close both at the same time. (A FIN
    *without* a prior close_notify constitutes a truncation attack, which
    the API should report to the application.)

    So, in practice, once a peer has received a close_notify+FIN, any data
    it has left to send cannot be sent, and indeed must constitute an error
    in the application protocol.

    In other words there can be no shutdown-for-write in SSL.

    EJP

  6. Re: SSL/TCP Connection termination results in RST

    On Thu, 05 Jun 2008 11:58:17 -0700, Chandler Bing 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.


    This behavior occurs when one side wants to close the connection and the
    other doesn't.

    There is something like half-close, where one application closes it's
    side of the stream, but still can receive data from the other side. What
    you see on the wire is what looks like a half-close.

    But half-closes are rare and the behavior you see is consistent with one
    side doing a full close and the other side that does not close but keeps
    sending.

    IIRC, but I may be wrong on this, SSL shuts down the connection in the
    SSL layer before shutting down on the TCP layer. So this sounds like a
    bug in one -- or both -- of the SSL stacks.

    M4

  7. Re: SSL/TCP Connection termination results in RST

    Martijn Lievaart wrote:
    > IIRC, but I may be wrong on this, SSL shuts down the connection in the
    > SSL layer before shutting down on the TCP layer. So this sounds like a
    > bug in one -- or both -- of the SSL stacks.


    That's correct. And SSL is obliged to respond to an incoming
    close_notify by closing its own end. But if it is writing, not reading,
    it doesn't have the opportunity to see the close_notify. So it writes.
    So the peer responds with RST. So it's a bug in the application
    protocol. The same thing would happen if it was a plaintext connection.

  8. Re: SSL/TCP Connection termination results in RST

    On Jun 5, 11:58*am, Chandler Bing 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.
    >
    > I have packet captures, but I'm not sure how to post them or share
    > them out.


    This is normal if you try to make SSL support TCP's half-closed
    semantics. SSL doesn't fully support TCP's half-closed semantics, in
    the sense that SSL's half-closure doesn't map to TCP's half-closure
    exactly. One consequence can be the abnormal termination of a
    connection as seen at the TCP layer.

    The only thing that matters is that the SSL connection terminated
    normally. What do the SSL layers on both ends say?

    DS

  9. Re: SSL/TCP Connection termination results in RST

    David Schwartz wrote:
    > This is normal if you try to make SSL support TCP's half-closed
    > semantics. SSL doesn't fully support TCP's half-closed semantics, in
    > the sense that SSL's half-closure doesn't map to TCP's half-closure


    'SSL's half closure' doesn't even exist. You can't half-close an SSL
    connection for write and expect to read anything from it.

    It seem to me that the OP's problem would happen even if there was no
    SSL involved.

  10. Re: SSL/TCP Connection termination results in RST

    On Jun 12, 9:09*pm, EJP wrote:

    > 'SSL's half closure' doesn't even exist. You can't half-close an SSL
    > connection for write and expect to read anything from it.


    You can send a 'close notify' to the other side. At this point, the
    SSL connection is half-closed. (This is not quite the same as TCP's
    half-closure.) The other side may continue to send data at this point,
    as it has not even received your 'close notify' yet.

    > It seem to me that the OP's problem would happen even if there was no
    > SSL involved.


    Possible, but there are unique aspects to SSL. For example, SSL
    explicitly permits you to send a 'close notify' and then close the
    underlying TCP connection. If you do this just after the other side's
    'close notify' has been received, a TCP RST will result. There is no
    directly analogous TCP-only scenario.

    DS

  11. Re: SSL/TCP Connection termination results in RST

    On Jun 5, 7:07*pm, EJP wrote:
    > Chandler Bing 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.

    >
    > It's correct for SSL. RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt) #7.2..1:
    >
    > * * '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.'
    >
    > Now the RFC doesn't mandate a strong connection between SSL connections
    > and connections of the underlying transport, so in theory close_notify
    > != FIN, but, in practice, SSL APIs close both at the same time. (A FIN
    > *without* a prior close_notify constitutes a truncation attack, which
    > the API should report to the application.)
    >
    > So, in practice, once a peer has received a close_notify+FIN, any data
    > it has left to send cannot be sent, and indeed must constitute an error
    > in the application protocol.
    >
    > In other words there can be no shutdown-for-write in SSL.
    >
    > EJP


    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



  12. Re: SSL/TCP Connection termination results in RST

    On Jun 12, 8:25*pm, David Schwartz wrote:
    > On Jun 5, 11:58*am, Chandler Bing 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.

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

    >
    > This is normal if you try to make SSL support TCP's half-closed
    > semantics. SSL doesn't fully support TCP's half-closed semantics, in
    > the sense that SSL's half-closure doesn't map to TCP's half-closure
    > exactly. One consequence can be the abnormal termination of a
    > connection as seen at the TCP layer.
    >
    > The only thing that matters is that the SSL connection terminated
    > normally. What do the SSL layers on both ends say?
    >
    > DS


    What I'm seeing is that the CCT is initiating a TCP close without
    closing the SSL session (close_notify). After the CCT's FIN, it does
    not acknowledge any data from the server. The server after attempting
    to send and re-send the data several times ultimately responds with a
    close_notify and a FIN, which is ignored. The CCT finally RST the
    connection, sometimes several times.

  13. Re: SSL/TCP Connection termination results in RST

    On Jun 12, 10:38*pm, David Schwartz wrote:
    > On Jun 12, 9:09*pm, EJP wrote:
    >
    > > 'SSL's half closure' doesn't even exist. You can't half-close an SSL
    > > connection for write and expect to read anything from it.

    >
    > You can send a 'close notify' to the other side. At this point, the
    > SSL connection is half-closed. (This is not quite the same as TCP's
    > half-closure.) The other side may continue to send data at this point,
    > as it has not even received your 'close notify' yet.
    >
    > > It seem to me that the OP's problem would happen even if there was no
    > > SSL involved.

    >
    > Possible, but there are unique aspects to SSL. For example, SSL
    > explicitly permits you to send a 'close notify' and then close the
    > underlying TCP connection. If you do this just after the other side's
    > 'close notify' has been received, a TCP RST will result. There is no
    > directly analogous TCP-only scenario.
    >
    > DS


    This sounds like the scenario we're seeing. The CCT closes the TCP
    session without closing the SSL session and then ignores the server
    completely until the CCT resets the connection. The server attempts
    to send and resend the final data and then an encrypted alert
    (close_notify?) and close the TCP session. I don't know enough about
    SSL to determine what the server is ultimately sending. Wireshark
    just shows it as an encrypted alert, message type 21. Is that an
    error, or is that a close_notify?

    Chandler Bing

  14. Re: SSL/TCP Connection termination results in RST

    Chandler Bing wrote:
    > (close_notify?) and close the TCP session. I don't know enough about
    > SSL to determine what the server is ultimately sending. Wireshark
    > just shows it as an encrypted alert, message type 21. Is that an
    > error, or is that a close_notify?
    >
    > Chandler Bing


    Wireshark does have the ability to decrypt SSL packets if you can
    provide it with the keys.

    Navigate as follows:

    Edit menu | Preferences | Protocols | SSL | RSA Keys list:

    It can decrypt IPSec, TACACS+, RADIUS, etc.

    Best Regards,
    News Reader

  15. Re: SSL/TCP Connection termination results in RST

    On Jun 18, 11:20*am, Chandler Bing wrote:

    > What I'm seeing is that the CCT is initiating a TCP close without
    > closing the SSL session (close_notify). *After the CCT's FIN, it does
    > not acknowledge any data from the server. *The server after attempting
    > to send and re-send the data several times ultimately responds with a
    > close_notify and a FIN, which is ignored. *The CCT finally RST the
    > connection, sometimes several times.


    I believe that attempting a normal TCP close without sending an SSL
    close_notify is a breach of the SSL protocol.

    DS

+ Reply to Thread