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: Jeffrey Walton <noloader@xxxxxxxxx>
Date: Wed, 3 Jun 2009 10:59:11 -0400
> Well written analysis.  I would have added to verify icmp messages across
>  the path so mtu path discovery would actually work.
And thanks for helping out.

Jeff

On 6/3/09, Robert D. Scott <robert@xxxxxxx> wrote:
> 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
>
> [SNIP]
>
>  -----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
>
> [SNIP]