locked
tsgu parser doesn't kick in? RRS feed

  • Question

  • Hi All,

    I'm trying to view a TS Gateway capture using NetMon 3.4 and the Dec 2011 parsers. I have enabled the Windows parser, but when I load a TS Gateway flow, the parser doesn't kick in and all that NetMon recognizes and decodes are TCP and TLS packets.

    Am I missing something?


    • Edited by Filofel Tuesday, March 13, 2012 1:36 PM
    Tuesday, March 13, 2012 1:33 PM

All replies

  • Usually traffic over TLS is encryted, if that's the case you'd have to decrypt it first.  If it is decrypted, or using a null encryption, then we might need to add some code to SSL.NPL to parse TSGU.  SSL.NPL has a switch statement for port in "struct SSLApplicationData", which probably also needs to be updated.  But I'd need some more information about the traffic you see.  Normaly TSGU rides on MSRPC, and perhaps this riding on HTTP, but I'd like to see an example of the trace first.

    Would it be possible to share a trace (like on skydrive or dropbox)?

    Thanks,

    Paul

    Wednesday, March 14, 2012 1:58 PM
  • Hi Paul, 

    Thanks for your help. 
    As a starting point, I looked for a way to config TS Gateway to run over HTTP (rather than HTTPS), but failed: The only clues I found all said that was impossible, even though the MS-TSGU spec mentions the protocol supports HTTP as well as HTTPS. That's how I ended up with TLS in my traces.
    If there is a way I missed to config TS Gateway for plain port 80 HTTP (or to convince it some way to encrypt using ESP_NULL), I'd sure love to know it. My friendly TS Gateway admin knows of none either. 
    So I ended up capturing the flow the TS Gateway (and client) dialog generated, ie. the HTTPS one.

    Now since there was a TSGU filter, I assumed it was able to handle the one and only case TS Gateway could apparently generate - HTTPS - the problem being I found no way to feed it my .pfx certificate, so I wasn't really convinced either it could work at all. I posted my question after testing confirmed my guess. 

    Since then, I have found out about NMDecrypt, and I'm currently experimenting with it:  
    NMDecrypt is able to decrypt a single conversation on a run.  
    The whole thing is very confusing because the original TCP/TLS capture already shows a hierarchy of 7 distinct encrypted conversations, and figuring out what to decrypt became a problem in itself.  
    The MS-TSGU spec indicates that the client creates two TCP connections to the TS Gateway, so I started by running NMDecrypt on those two conversations (and thus running NMDecrypt twice from the original capture, generating two decrypted half-traces).  
    This gives interesting results that I'm studying right now, but I have not figured out yet how to merge back the two decrypted captures this process generates into a single one. I'm not a NetMon expert (yet :) ), and here also, if there is a way to do this, I'd sure like to know!  It seems that there is also the capability of chaining NMDecrypt runs (running NMDecrypt on the result of a previous NMDecrypted capture), but it's very tricky to figure out the sequence of conversations to decrypt, and I've already generated duplicated decrypted frames this way, so I'm not sure it's such a good idea either. 

    This is where I am at this point. The whole process is a tad more involved than what I initially expected when I saw that there was a tsgu filter in NetMon. :)

    I just signed into skydrive and created a private folder with the cap file I wish to share with you, but the "Share folder" function on the page asks me for your email (to send you the URL to the folder, I guess). 
    Can you send it to me privately?




    • Edited by Filofel Wednesday, March 14, 2012 4:18 PM
    Wednesday, March 14, 2012 4:11 PM
  • Ah, and

    > Normaly TSGU rides on MSRPC, and perhaps this riding on HTTP

    According to MS-TSGU, Remote Desktop Gateway Server Protocol rides on RPC over HTTP (MS-RPCH).  So we have RPC, plus MS-RPCE, plus MS-RPCH, plus MS-TSGU, with RDP somewhere inside.

    That's where NetMon decoding becomes really precious!

    Wednesday, March 14, 2012 4:27 PM
  • You can decrypt multiple conversations with NMDecrypt, but only under certain conditions.  Assuming you were able to get one decrypted, I would just try two (either by selecting the IP node instead, or create a filter on the TCP ports).  If you run into issues, there are work arounds, however I can't say how they might work with this particular traffic. 

    I'm not sure how to contact you directly, but you can contact me privately from the blog, http://blogs.technet.com/netmon.  And then I can respond with the info.

    Paul

    Monday, March 19, 2012 7:44 PM
  • Paul,

    > you can contact me privately from the blog, http://blogs.technet.com/netmon.  And then I can respond with the info.

    I just did.  I have a small capture, cert and everything ready for you to see.

    I already tried what you suggest, but the problem is that according to what I decrypt and in which order (large number of combinations available), I get different partial results, with parts that don't get decrypted and/or parts that get duplicated decryptions.

    And so far, I found no way to decrypt the whole...

    Confusing.  And very frustrating. :(



    Tuesday, March 20, 2012 1:24 PM
  • So I was able to decrypt your trace, but only by doing each TCP session separately.  The issue is that these are intertwined and the NMDecrypt expert doesn't deal with that properly.  If you do each separately, there is no easy way to re-interwine them after the fact.  So I'm not certainly this will provide what you need.

    As for the TSGU traffic, if I decrypt each TCP conversation separately, I do see TSGU traffic parsed, and in many cases RDP traffic on top.  One caveate here is that it might be further fragmented and there might be some cases there where we can't completely reassemble that data.  But I'm not familiar enough with that kind of traffic to understand if this is the case.

    Keep in mind that once you finish the decryption, all of the original messages are there.  To see only the decrypted ones you can do a filter of "DecryptedPayloadHeader".

    Paul

    Thursday, March 22, 2012 5:52 PM
  • Paul,

    Looks like you came to the same results as I did, and the same unfortunate conclusion, too <sigh>.

    There are a few other problems that I noticed: One is that looking at the TLS packets, some have Layer-1 application data, and some have Layer-1 and Layer-2 application data. But unfortunately, it looks like NMDecrypt only decrypts the Layer-1 application data.

    >But I'm not familiar enough with that kind of traffic to understand if this is the case.

    Neither me, and that's the problem: Since I couldn't make sense out the spec, I decided to start by looking at a real TS Gateway flow -- it just happens that it's not much easier!

    > Keep in mind that once you finish the decryption, all of the original 
    > messages are there. To see only the decrypted ones you can do a
    > filter of "DecryptedPayloadHeader".

    Yes, and selecting the conversation immediately below the TLS one is useful, too.

    Thanks for your help!

    Friday, March 23, 2012 12:09 PM