Missing client hello

Jul 24, 2012 at 6:29 PM

I'm tracing some traffic that's passing from a TMG front-end to an app server via SSL bridging. The certificates are all installed properly and traffic is flowing fine. The basic sequence I"m using is:

  1. Start the trace
  2. Log in with the client app and do some stuff.
  3. Stop the trace
  4. Analyze the trace.

I can capture packets with NM, but when I try to decrypt them I get an error that the client hello isn't zero-length. Sure enough, when I look at the captured packets, the first client hello I see is a renegotiation. Obviously TMG and/or the app server is keeping the SSL connection TMG<->server open such that when the client gets a new session client<->TMG at login, but the existing TMG-server connection is reused.

Is there a way for me to stop this behavior, or to somehow get nmdecrypt to use the renegotiated hello instead? Setting the timeout on the SSL listener on TMG to a very low value makes the app continually complain that it's losing connectivity to the server because it only affects the client-TMG link.

Jul 24, 2012 at 6:38 PM

It's up to the application to decide when to free sessions.  The only thing I can tell you for sure is that you should restart both sides before starting the trace.



Jul 25, 2012 at 1:40 PM

Thanks, Paul. As a further test, I did the following:

  1. Stopped w3svc on the app server.
  2. Tested the publishing rule on TMG. As expected, the test failed both to 8080 and 4443.
  3. Started a trace on the app server.
  4. Started w3svc on the app server.
  5. Tested the publishing rule on TMG. As expected, the test succeeded.

I can see both the HTTP and SSL connection frames, but sure enough, the initial client hello session ID is still not zero. There is no traffic shown in netmon between the TMG and app server other than the rule tests, e.g. there aren't any sneaky out-of-sequence packets or anything. The session is obviously being set up somewhere, but darned if I know where; I'll try stopping the TMG services as step 0 of this process and see if that makes any difference. 

Jul 25, 2012 at 2:31 PM

Stopping both the TMG and w3svc services, then starting the trace, allowed me to capture the initial client-hello. I'm still not seeing the actual app server data I expected (nmdecrypt shows it as a binary blob labeled "SSL application data"), but this is progress. Onward…

Jul 25, 2012 at 2:54 PM

Glad you got that part sortted out. 

Remember that the original traffic is still there.  Filter on DecryptedPayloadHeader to focus on the decrypted frames.

What is the protocol ontop of SSL?  We have to manually hook up the protocol in the SSL parser, so maybe this needs to be done for your case.  In the past there have been others we've added.  I did find another case that seemed similar where TSGU was the protocol and apparently it seemed to be working for me.  But perhaps there are mutliple protocol possibilities here.

Also, when you have a client hello that is reused, you might want to read this blog as it has details about special considerations for this case.  http://blogs.technet.com/b/netmon/archive/2011/03/03/nmdecrypt-expert-updates-version-2-3.aspx


Jul 25, 2012 at 3:15 PM

In this case, the actual protocol is (should be) SIP, since I'm using Lync. However, I'm actually looking at data to/from mobile devices using Lync MCX, so it's possible that they're using some other protocol, kinda like Exchange ActiveSync does with WBXML. Thanks for the link, too; I'd already read that, and it will come in handy when I get to the meat of my testing, which involves watching traffic between two devices that are simultaneously talking to the server.