none
Filtering based on high-level protocols RRS feed

  • Question

  • I'm using Network Monitor's SSL parser to detect SSL connections.  Initially I've tested via Network Monitor's GUI, which works fine.  I'm now trying to use the same filters via the NM API, but this works only partially, as in the example below.  I'm probably missing something simple and would appreciate any suggestions.

    As an example, the following filter detects the initial SSL server handshake (ServerHello):

    TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType == 0x2

    This filter works fine via both the GUI and NmAddFilter().

    On the other hand, the filter below should detect the next SSL server handshake (Certificate):

    TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType == 0xb

    This works via the GUI, but not via the NM API.  While NmAddFilter() succeeds, NmEvaluateFilter() just filters out everything.

    I believe this happens because both the SSL ServerHello and Certificate messages are contained in the same frame (and TCP packet).  In the frame callback, NmParseFrame() seems to parse only the beginning of the frame, which contains ServerHello.  Certificate immediately follows ServerHello, but NmParseFrame() does not seem to detect this.

    Is there any way to get NmEvaluateFilter() to work the same way as filters in the GUI?  That is, the filter should succeed even if it references fields inside a frame, not just at the frame's beginning.


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

    Wednesday, October 24, 2012 11:04 AM

Answers

  • Hi Paul,

    My guess would be that the API is shortcutting to the only the first one.  Network Monitor wasn't designed with having multiple payloads in mind initially and the UI takes some liberties at guessing what you're looking for to find both.  The API is a bit more explicit, and I'm guessing that's where you're running into trouble.

    I would look at the NmDecrypt expert and see if it correctly interprets your trace to see what they may be doing differently.  Otherwise, you may have to iterate over everything in the packet to understand its structure. 

    Thanks,


    Michael Hawker | Program Manager | Network Monitor

    • Marked as answer by Paul E Long Thursday, November 1, 2012 5:18 PM
    Monday, October 29, 2012 5:59 PM
    Moderator

All replies

  • With out seeing the trace, I can't say for sure, but my guess is that in order to decode this value you need to enable conversations in the API.  There are some examples in the help.  Have you enabled conversations?

    Paul

    Wednesday, October 24, 2012 5:59 PM
  • I added code to enable conversations, as in the "Showing Conversations" sample, but to no effect.

    When running the "Iterating Frame Fields" sample, I can actually see the two SSL records in the frame (ServerHello and Certificate, as shown below).  The filter to detect ServerHello (0x02) works fine, but a similar filter for Certificate (0x0B) never passes anything if used via the NM API (works fine via the GUI).  The reason seems to be that ServerHello and Certificate are in the same frame here, though they could be sent in different frames (and TCP packets) in general.

    My objective is to have a working NM API filter for "internal" structures like Certificate.

      Frame: Number = 11, Captured Frame Length = 1514, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:...
    + Ipv4: Src = xx.xx.xx.xx, Dest = yy.yy.yy.yy, Next Protocol = TCP, ...
    + Tcp: Flags=...A...., SrcPort=HTTPS(443), DstPort=39771, PayloadLen=1460, ...
      TLSSSLData: Transport Layer Security (TLS) Payload Data
    - TLS: TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.
      - TlsRecordLayer: TLS Rec Layer-1 HandShake:
         ContentType: HandShake:
       + Version: TLS 1.0
         Length: 74 (0x4A)
       - SSLHandshake: SSL HandShake ServerHello(0x02)
          HandShakeType: ServerHello(0x02)
          Length: 70 (0x46)
        + ServerHello: 0x1
      - TlsRecordLayer: TLS Rec Layer-2 HandShake:
         ContentType: HandShake:
       + Version: TLS 1.0
         Length: 2903 (0xB57)
       - SSLHandshake: SSL HandShake Certificate(0x0B)
          HandShakeType: Certificate(0x0B)
          Length: 2896 (0xB50)
        + Cert: 0x1
    

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

    Thursday, October 25, 2012 1:39 AM
  • Maybe a simpler question: Given the parsed frame I showed, would the two filters in my initial post be expected to work correctly?  They do work fine via the Network Monitor GUI, but only the first one works via the NM API (NmAddFilter()) with conversations enabled.  I'll keep experimenting, but thanks for any suggestions.


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

    Friday, October 26, 2012 10:20 PM
  • Hi Paul,

    My guess would be that the API is shortcutting to the only the first one.  Network Monitor wasn't designed with having multiple payloads in mind initially and the UI takes some liberties at guessing what you're looking for to find both.  The API is a bit more explicit, and I'm guessing that's where you're running into trouble.

    I would look at the NmDecrypt expert and see if it correctly interprets your trace to see what they may be doing differently.  Otherwise, you may have to iterate over everything in the packet to understand its structure. 

    Thanks,


    Michael Hawker | Program Manager | Network Monitor

    • Marked as answer by Paul E Long Thursday, November 1, 2012 5:18 PM
    Monday, October 29, 2012 5:59 PM
    Moderator
  • Thanks.  My solution (or workaround) was basically what you described; i.e., enumerate all fields in the frame, search for particular field names (e.g., "SSLHandshake" and "ContentType"), and retrieve their field values.  This implements filtering, but maybe not as efficiently as bona fide NM filters.  It will do for now, though it would be good to know whether there's a way to do this via NmAddFilter()/NmEvaluateFilter().


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

    Tuesday, October 30, 2012 4:20 AM
  • It seems like you've found a bug with the API and filtering.  You're work around is the probably the easiest way to address this problem. 

    Paul

    Thursday, November 1, 2012 5:17 PM