Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

From: "Sheahan, John" <John.Sheahan@xxxxxxxxxxxxx>
Date: Sun, 13 Apr 2008 17:28:01 -0400
sorry...please ignore this message....I had opened up my trace with
Sniffer Pro so I wasn't seeing the nice relative sequence number feature
that Wireshark offers. Also, the reason I wasn't seeing the Encryption
alert was also because it's not visible with Sniffer Pro. I am only able
to see SSLv3 information with Wireshark, definately another advantage.

My question is, after doing some research on Encryption Alert (21), it
seems to imply some kind of fatal error yet you say that the ssl
connection gets closed cleanly?

thanks

jack 

-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sheahan,
John
Sent: Sunday, April 13, 2008 1:15 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Same SEQ number but different ACKs

I'm sorry but I'm having a bit of difficulty walking through the trace
with you. I don't see any ACK=23503 or ACK=23504 anywhere in the trace?

-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Sunday, April 13, 2008 10:08 AM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Same SEQ number but different ACKs

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
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users