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: Mon, 14 Apr 2008 15:16:57 -0400
thanks alot Sake 


 

-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Monday, April 14, 2008 2:09 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Same SEQ number but different ACKs

Hi John,

Well, a search for the word alert won't help you, as the alert in SSL is
just a numerical value. The words "Encrypted Alert" are the Wireshark
description to the numerical value :-)

If you open frame 44 and expand all subtrees within the packet detail
pane, you will see the Encrypted Alert. To do this however, you need a
recent version of Wireshark as there has been a bug fixed with proxied
SSL connections a few months back. You will also need to have the
following protocol preferences enabled:

TCP: "Allow subdissector to reassemble TCP streams"
SSL:  "Reassemble SSL records spanning multiple TCP segments"
SSL:  "Reassemble SSL Application Data spanning multiple SSL records"

I attached a text file that shows how frame 44 is dissected in my
version of Wireshark with my preferences.

The way I found it was that I was interested whether or not the proxy
issued an Close Notify, so I looked at the last SSL records that were
sent from the proxy to the client, which were at the end of frame 44 :-)

If you are able to reproduce the issue, you might want to capture
traffic on the client as well as on the proxy to see whether the TCP RST
was coming from the proxy or the PIX. My bet would be that it is
generated by the PIX as it does not like the way the client closes the
connection and therefor it tries to shutdown the TCP-session on it's
own. I just don't have enough knowledge of the PIX to check whether this
is indeed one of its features :-)

Cheers,
      Sake



----- Original Message -----
From: "Sheahan, John" <John.Sheahan@xxxxxxxxxxxxx>
To: "Community support list for Wireshark"
<wireshark-users@xxxxxxxxxxxxx>
Sent: Sunday, April 13, 2008 7:02 PM
Subject: Re: [Wireshark-users] Same SEQ number but different ACKs


> for starters, I can even find the Encryption Alert that you are
talking
> about :-)
> I went straight to packet 44 and don't see it anywhere. I did a search
> for the word "alert" in the whole trace and didn't find it either. How
> did you find that?
>
> Great catch on the ACK flag not being set in frame 50, also if you
look
> at the ACK itself, it doesn't match any SEQ numbers of my client. I
> don't have any IPS device in the mix. My client goes through a Pix
> firewall to a dmz where the proxy server is.
>
> I really appreciate you thinking this through with me.
>
> jack
>
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
> Sent: Sunday, April 13, 2008 12:03 PM
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] Same SEQ number but different ACKs
>
> On Sun, Apr 13, 2008 at 04:07:42PM +0200, Sake Blok wrote:
>> 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.
>>
> [...]
>> frame 50: Proxy sees data *after* the client has acknowledged the TCP
>>           session teardown (ACK=23504 in frame 47) and sends RST
>
> I just remembered your comment about the high ACK number for the RST
> packet and took another look at it. Frame 50 also doesn't have the ACK
> flag set. This is also not according to RFC and indeed it does have a
> sequence number that does not belong to this tcp session.
>
> Are you sure it's the proxy that sent this packet? Couldn't it have
been
> an Intrusion Detection and Prevention System (IDP) that generated this
> packet?
>
> 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
>