locked
Incomplete reassembly RRS feed

  • Question

  • I've been using reassembly on SSL traffic and came across cases where Network Monitor reassembles SSL records only partially.  However, the current Message Analyzer beta reassembles these frames completely and correctly.

    As an example, below are several captured frames that should be reassembled into one SSL record.  It would be unwieldy to post the entire trace here, but hopefully this will suffice.  (These results are from a capture when opening https://www.vanguard.com/ in a browser.)

    33 8:43:23 AM 10/30/2012 0.7610158  xx.xx.xx.xx yy.yy.yy.yy TLS TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate. {TLS:25, SSLVersionSelector:24, TCP:16, IPv4:15}

    34 8:43:23 AM 10/30/2012 0.7610158  xx.xx.xx.xx yy.yy.yy.yy TCP TCP:[Continuation to #33]Flags=...A...., SrcPort=HTTPS(443), DstPort=57746, PayloadLen=1380, Seq=4269133269 - 4269134649, Ack=1488995519, Win=4140 (scale factor 0x0) = 4140 {TCP:16, IPv4:15}

    36 8:43:23 AM 10/30/2012 0.7614188  xx.xx.xx.xx yy.yy.yy.yy TCP TCP:[Continuation to #33]Flags=...AP..., SrcPort=HTTPS(443), DstPort=57746, PayloadLen=1380, Seq=4269134649 - 4269136029, Ack=1488995519, Win=4140 (scale factor 0x0) = 4140 {TCP:16, IPv4:15}

    37 8:43:23 AM 10/30/2012 0.7614188  xx.xx.xx.xx yy.yy.yy.yy TLS TLS:Continued Data: 164 Bytes {TLS:25, SSLVersionSelector:24, TCP:16, IPv4:15}

    In the reassembled capture (filtered via PayloadHeader), frames 33, 34 and 36 are reassembled, but the above #37 is skipped.  From inspecting the contents of #37, I can see that it would complete the SSL record.  However, reassembly fails to include #37.  Instead, #37 appears to be deleted and replaced by the reassembly of just 33, 34, and 36:

    37 8:43:23 AM 10/30/2012 0.7610158  xx.xx.xx.xx yy.yy.yy.yy TLS TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate. {TLS:25, SSLVersionSelector:24, TCP:16, IPv4:15}

    Is this expected?

    When I load the same capture into Message Analyzer beta, everything works correctly: #37 is included in the reassembly along with 33, 34 and 36, producing the complete SSL record.

    Anything I could try to get Network Monitor to behave similarly?  Thanks.

    PS: As mentioned above, this should be reproducible by capturing SSL traffic when opening https://www.vanguard.com/, at least as of today.


    :-( + :-) = :-) :-)

    Tuesday, October 30, 2012 12:10 PM

Answers

  • One major limitation of Netmon has always been handling streamed data.  Many times protocols work closely with TCP and line up their data segments so that they happen when TCP fragments data.  But sometimes, the upper protocol like TLS, streams ontop and has different “seams”.  This was basically impossible to do with NPL.

    Anyhow, we fixed it in Message Analyzer for sure.  Certainly a huge highlight for the new tool.

    If you use the API, you can handle the reassembly manually.  This is exactly what the nmdecrypt expert does.  It’s no simple task, but you can use that code on http://nmdecrypt.codeplex.com as a guide.

    Thanks,

    Paul

    Wednesday, October 31, 2012 2:16 PM

All replies

  • One major limitation of Netmon has always been handling streamed data.  Many times protocols work closely with TCP and line up their data segments so that they happen when TCP fragments data.  But sometimes, the upper protocol like TLS, streams ontop and has different “seams”.  This was basically impossible to do with NPL.

    Anyhow, we fixed it in Message Analyzer for sure.  Certainly a huge highlight for the new tool.

    If you use the API, you can handle the reassembly manually.  This is exactly what the nmdecrypt expert does.  It’s no simple task, but you can use that code on http://nmdecrypt.codeplex.com as a guide.

    Thanks,

    Paul

    Wednesday, October 31, 2012 2:16 PM
  • Thanks, that makes things clear.  Are there plans for a "Message Analyzer API" (successor to the NM API) that would expose these new capabilities?

    :-( + :-) = :-) :-)

    Wednesday, October 31, 2012 10:44 PM