Freigeben über

NMDecrypt Expert Updates - Version 2.3

  • Artikel

When I first wrote about NMDecrypt Expert in this blog I mentioned some limitations. There have also been bugs reported since then. I decided I would fix some of these problems and address some of the limitations. My hope is to make this tool even more useful, but also to point out other ways community members could help extend the functionality further and get involved now that our Experts are open source. Below I will call some of these updates out explicitly.

Now You Can Select a IPv4/IPv6 Conversation

Previously you had to select the specific TCP conversation in order for the expert to work. This TCP conversation also had to contain the full TLS/SSL session setup, because the expert needs this data to do the decryption. However there are cases where a single IE session would spawn multiple TLS/SSL sessions, with only the first session containing the TLS/SSL session setup. Now, the expert can work in situations where multiple SSL sessions exist with two given restrictions:

  1. The trace can only contain traffic that is associated with the private key you’ve provided. If there is other traffic that happens simultaneously, the expert will fail. Community: It should be possible to compare the certificate path provided with the one used during negotiation. With this mapping you could potentially decrypt all traffic that uses the same certificate. Perhaps we could also just ignore the failures and continue on.
  2. Sessions can’t be intermingled. When the expert decrypts traffic, there’s a running check called a MAC (Message Authentication Code). State between separate TCP conversations is not maintained. So data from another TCP session messes up the MAC calculation and the expert fails. The work around for this problem is to manually save each TCP session in order to another file. This is simple using the Frame Buffer manager feature in the UI. Just select each TCP conversation, Ctrl+A to select all frames, and right click to open the Frame Buffer manager. Once you create a new file continue to add frames from each session in order to the same file, and then close the file once you are done. Community: While it might be hard to maintain state in the expert, I think it would be simple to make multiple passes though the capture file; limiting each pass to a single TCP conversation.

Support for Alternate Network Paths

The expert examines the traffic and derives a fully qualified path from the frame it’s examining. For instance if the path it sees is Ethernet.IPv4.IPv6.TCP, it uses this as a seed to understand the root for the TLS/SSL specific data. However, each of these is verified against known paths. In order to support new paths, I’ve added a few more common paths for wireless and ESP over IPv4/IPv6. Incidentally there was also a bug fix for IPv6 traffic that I fixed in this area. Community: If there are other network paths that we need to support, this is a very easy change. Also related to this is the support for TLS/SSL for other protocols. Currently we support LDAP and HTTP, but this would be easily extended to support other protocols.

TCP Fragmented Data

The Expert depended on the ability of Network Monitor parser to properly re-assemble TCP data. However, there are certain limitations where data does not align on a TCP frame boundary. This is because TCP streams data and therefore it’s possible for the data to break on non-frame bounds. However, from the TLS/SSL perspective, the data that describes each data segment is described by the protocol. So I modified the expert to find when there was not enough data to account for a full TLS/SSL Segment. In those cases, I reassembled that data manually. Community: There are bound to be problems between various versions of TLS/SSL. My main test case was TLS 1.0, so be aware for variances in other protocols that could cause issues.

Get Involved

The link to the latest version of the expert is available on our Expert Codeplex site. By highlighting some of the remaining issues I’m hoping to get more community involvement to further update this expert. And with the move to the OuterCurve Foundation contributing has never been easier.

Comments

  • Anonymous
    January 01, 2003
    When TLS/SSL negotiates the first time, it creates a session ID.  Further sessions can reuse this ID, however there is not enough information in those sessions to decrypt the data.  You'll have to make sure you get the initial session setup, which usually means restarting the client side.  One update with the expert, mentioned above, is being able to handle an entire IPv4/IPv6 conversation.  However, the first session still has to have the full session setup and not reuse a session ID.  The way to determine if you have a reused session is to look at the  SessionIDLength, it should be zero.  The following filter will see if you have any decrypt-able traffic for TLS. TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ClientHello.SessionIDLength == 0x0

  • Anonymous
    January 01, 2003
    I can't tell for sure what the issue is, but the following is a check list based on other instance of this same error:

  1.  Make sure you've selected a single TCP conversation with a full SSL session setup.  This is the best way to test things are working properly.
  2.  Make sure you have the latest parsers from http://nmparsers.codeplex.com.
  3.  Verify you have captured both SSL and TCP traffic to be decrypted. In the log file you should see lines where it finds the key in the server hello.  I might be able to help further if you supply the complete log (perhaps on skydrive or something similar).   BTW, the forums on social.technet.microsoft.com/.../threads might be a better place to ask these types of questions. Thanks, Paul

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    March 16, 2011
    I keep getting this when I try and use it: clienthello contains a reused session id and the initial session setup is missing. session id length in the first clienthello must be zero. you can try to restart the application that is generating the secure connection or narrow down the trace so it contains only one session id.

  • Anonymous
    March 18, 2011
    Thank you...  Appreciate your time and explanation..  

  • Anonymous
    October 05, 2011
    I am not able to decrypt, I am getting following error in the log. Computing ServerIV for next application data Exception: Object reference not set to an instance of an object.   at SSLDecryptionExpert.AppDataDecryption.LogApplicationDataDetails(String sourceIP, CipherSuiteInfo cipherSuite)   at SSLDecryptionExpert.AppDataDecryption.DecryptSslApplicationData(String sourceIP, CipherSuiteInfo cipherSuite) Exception: Object reference not set to an instance of an object.   at System.Security.Cryptography.HMAC.InitializeKey(Byte[] key)   at SSLDecryptionExpert.AppDataDecryption.VerifyMacValueTLS(CipherSuiteInfo cipherSuite, String sourceIP)   at SSLDecryptionExpert.AppDataDecryption.VerifyMacValue(CipherSuiteInfo cipherSuite, String sourceIP)   at SSLDecryptionExpert.AppDataDecryption.DecryptSslApplicationData(String sourceIP, CipherSuiteInfo cipherSuite)   at SSLDecryptionExpert.SSLDecryption.DecryptApplicationData(Int32[] value, String sourceIP)   at SSLDecryptionExpert.SSLDecryption.ParsedFrameInformation(IntPtr parsedFrame, UInt32& frameNumber, Boolean& isKeyBlockComputed, Boolean& decryptedAppDataPacket, Boolean& exitOnError, NMFilters filter)   at SSLDecryptionExpert.SSLDecryption.StartDecryption(Dictionary2 property, String& decryptionResult)   at SSLDecryptionExpert.SSLDecryption.SslDecryptCapture(Dictionary2 property, String& decryptionResult)