Wireshark · Wireshark-users: Re: [Wireshark-users] Same SEQ number but different ACKs

[Sake Blok <sake@xxxxxxxxxx>]

On Sun, Apr 13, 2008 at 09:27:41AM -0400, Sheahan, John wrote:
> this is actually code that runs on several servers that exchanges XML
> data over HTTPS using the proxy. I didn't see the Encrypted Alert but
> I'm going to recheck for that. I have enclosed the trace of one
> conversation.

Thanks for the trace, it shows that the proxy also sent an "Encrypted
Alert" in frame 44. This means it is closing the SSL session cleanly
first, before closing the TCP connection.

However, it looks like the client is mixing up closing the SSL session
and closing the TCP session. Walk with me:

frame 44: proxy sends data and issues an ssl termination request
frame 45: proxy issues a TCP FIN to close TCP after closing SSL
frame 46: client ACKs the data from frame 44 (ACK=23503)
frame 47: client ACKs the FIN from frame 45 (ACK=23504)
frame 48: client decides to close SSL cleanly and sends "Encrypted Alert"
          but in the TCP stream it ACKs the last received data (23503)
frame 49: client closes TCP and uses ACK=23503, while it actually 
          should have used ACK=23504
frame 50: Proxy sees data *after* the client has acknowledged the TCP
          session teardown (ACK=23504 in frame 47) and sends RST

I'm not 100% sure if this is violating the RFC, but it sure looks like
a violation to me. I think the client should not have sent frame 47
until it had finished sending data (ie, it should have been sent after
frame 48). After that, the FIN should also have used ACK=23504.

Cheers,
    Sake