ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Interpreting TLS v1 Capture (Anti-Debug Trick?)

From: "Robert D. Scott" <robert@xxxxxxx>
Date: Wed, 3 Jun 2009 08:13:03 -0400
Well written analysis.  I would have added to verify icmp messages across
the path so mtu path discovery would actually work.

Robert D. Scott                 Robert@xxxxxxx
Senior Network Engineer         352-273-0113 Phone
CNS - Network Services          352-392-2061 CNS Phone Tree
University of Florida           352-392-9440 FAX
Florida Lambda Rail             352-294-3571 FLR NOC
Gainesville, FL  32611          321-663-0421 Cell


-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Wednesday, June 03, 2009 12:37 AM
To: wireshark-users@xxxxxxxxxxxxx
Subject: Re: [Wireshark-users] Interpreting TLS v1 Capture (Anti-Debug
Trick?)

On Tue, Jun 02, 2009 at 06:19:57PM -0400, Jeffrey Walton wrote:
> 
> > You might be a bit too paranoid here, but could you
> > send in the tracefile showing this behavior, as I...
> 
> The data in the packet in question (36 in the attached dump) is as
> follows. Does anything jump out at you? 

What jumps out to me is that the MSS option in the SYN is 1460 and in
the SYN/ACK it is 1452. Usually this means that some device in the
network is forcing a lower MSS because of tunneling or encryption. I
would expect the SYN to arrive at the server with 1452 too (as the
device would alter the MSS in both directions). However, the first large
frame from the server seems to be broken up in a 1452 and a 8 byte
segment (frame 38 and frame 36). The first part however is not sent and
is retransmitted after the client asked for it in frame 37. After that,
all goes well until the same thing happens starting at frame 51.

Looks like some problem on the intermediate network where a device is
segmenting the traffic, probably a proxy between the server (with a MSS
of 1460 between the proxy and the server) and the client (with a MSS of
1452 between the client and the proxy). But this proxy does not seem to
do a pretty good job...

Well, that's just my interpretation of course :-)

Cheers,
     Sake
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
 
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe