nmdecrypt Discussions Rss Feed

New Post: NMDecrypt not working.

mahatd — Thu, 06 Jun 2013 19:46:25 GMT

Hi Paul,
the logs have been emailed to you via the blog.
thanks
md

New Post: NMDecrypt not working.

PaulLong — Thu, 06 Jun 2013 18:35:53 GMT

I can't say for sure the log will tell me everything I need to know, but I suppose I can take a look and try to understand why you are getting your error. I have seen some strange issues with SSL in the past. The log should illuminate that problem.

Paul

New Post: NMDecrypt not working.

mahatd — Thu, 06 Jun 2013 18:30:34 GMT

Thanks again Paul,
when I apply the filter "TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ClientHello.SessionIDLength == 0x0" I do not see any frames.
However when I apply the filter "SSL.SslV2RecordLayer.ClientHello.SessionIDLength == 0x0" I do see the frame.

If I change my mask my source/dest ip's on the log, I think it does not have any other secure info?? Please correct me if this is a wrong assumption.
So sending the log with the masking should work, however I do not think I can send you the actual capture.

~md

New Post: NMDecrypt not working.

PaulLong — Thu, 06 Jun 2013 18:11:33 GMT

If you filter on "TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ClientHello.SessionIDLength == 0x0" the session you are trying to decrypt should show up. If the Client Hello has a value then that means it's reusing a session ID which means it can't decrypt because all the information isn't present as we need the full TLS session setup. You might have to restart the client or server to make sure all cached Session IDs are flushed.

If you TCP session does show up, then I'll probably have to get the log from you. You can contact me through the blog (http://blogs.technet.com/Netmon) which will allow us to start an email conversation.

Paul

New Post: NMDecrypt not working.

mahatd — Thu, 06 Jun 2013 18:04:40 GMT

Many thanks Paul.
Here is the top most portion of the log.
Where can I find the SessionID
thanks,
mahatd
-.-.-.-.-.-.- SSL Decryption Log -.-.-.-.-.-.-

Log Created On: 6/6/2013 1:14:55 PM

NMDecrypt Version: 2.3.4.0
NMAPIs Initialized.
Initializing Netmon Parsers...
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\ProgramData\Microsoft\Network Monitor 3\NPL\NetworkMonitor Parsers\Profiles\64BAA24A-0AAD-44e6-9846-3BE43D698FF6\sparser.npb.
Netmon Parsers initialized successfully.
Adding SSLVersionSelector Display Filter...
Display Filter added successfully
Adding Conversation.TCP.Id == 10 Conversation Filter...
Conversation Filter, Conversation.TCP.Id == 10 added successfully
SSL Version Filter added successfully
Adding Conversation.TCP.Id == 10 Conversation Filter...
Eval Parser Conversation Filter, Conversation.TCP.Id == 10 added successfully
This Netmon Version is supported
*Warning: We've tested with version: 03.04.2748.0001. Your version is: 3.4.2350.0 000000000. This might cause problems if the TLS/SSL parsers have changed significantly.

New Post: NMDecrypt not working.

PaulLong — Thu, 06 Jun 2013 17:48:07 GMT

It's hard to say from the log snippit you sent. Perhaps you can print the top portion of the log. This can help me decide what info I need next.

You could also verify that the full TLS negotiation occurs in your trace. The Session ID should be zero in the client request.

Paul

New Post: NMDecrypt not working.

mahatd — Thu, 06 Jun 2013 17:39:50 GMT

Hi All,
I recently tried to decrypt SSL traffic using this tool. I too ended up getting the same error. Can anyone confirm whether this fix has been stabilized?

I used NetMon 3.4(parser profiler - 3.4.2350.0)
NMDecrypt Version: 2.3.4.0

I selected just the TCP conversation and got the following error in the log:

Many Thanks. ( I could not figure out which byte needs to be removed as suggested above)

144,54: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS
Value: TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.; TLS Rec Layer-3 HandShake: Server Hello Done.
144,55: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer
Value:
144,56: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer
Value: TLS Rec Layer-1 HandShake:
144,57: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.ContentType
Value: HandShake:
Found Content Type: 22 (Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.ContentType)
144,58: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version
Value: TLS 1.0
144,59: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Major
Value: 3 (0x3)
144,60: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Minor
Value: 1 (0x1)
144,61: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Length
Value: 74 (0x4A)
144,62: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake
Value: SSL HandShake ServerHello(0x02)
144,63: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake
Value:
144,64: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType
Value: ServerHello(0x02)
Found Handshake Message 2 (Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType)
EXCEPTION: Simultaneous ClientHello message present
No Frames were decrypted, Netmon Filter Set may not match with current parser version. Use parser version 3.4.2345.1 or greater.

New Post: EXCEPTION: Simultaneous ClientHello message present

andersRson — Thu, 18 Apr 2013 09:46:03 GMT

I have the same problem, and the same situation - trying to decrypt ldaps traffic. It fails in the exact same way:

``` -.-.-.-.-.-.- SSL Decryption Log -.-.-.-.-.-.-

Log Created On: 2013-04-18 11:36:31

NMDecrypt Version: 2.3.4.0
NMAPIs Initialized.
Initializing Netmon Parsers...
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\ProgramData\Microsoft\Network Monitor 3\NPL\NetworkMonitor Parsers\Profiles\64BAA24A-0AAD-44e6-9846-3BE43D698FF6\sparser.npb.
Netmon Parsers initialized successfully.
Adding SSLVersionSelector Display Filter...
Display Filter added successfully
Adding Conversation.TCP.Id == 44 Conversation Filter...
Conversation Filter, Conversation.TCP.Id == 44 added successfully
SSL Version Filter added successfully
Adding Conversation.TCP.Id == 44 Conversation Filter...
Eval Parser Conversation Filter, Conversation.TCP.Id == 44 added successfully
This Netmon Version is supported
*Warning: We've tested with version: 03.04.2748.0001. Your version is: 3.4.2350.0 000000000. This might cause problems if the TLS/SSL parsers have changed significantly.
Opening Encrypted Capture File: C:\Users\runesand\Documents\Katalog\skat\cap\lewa2.cap
Creating Decrypted Capture File: C:\Users\runesand\Documents\Katalog\skat\cap\lewadecr.cap
Proposing Init Filter String of Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData
Using Init Filter String of Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.Tls.
Changing Conversation ID from 18446744073709551615 to 44
.................................................
Entered IsTLSSLPayloadFragmented: Frame 549
.................................................

...
<some frames left out>

...

Processing Frame Number: 551

Found 2936 Fields in Frame
551,0: Processing Field: PayloadHeader
Value: Reassembled Protocol=TCP, FrameCount=2,Length=1963
551,1: Processing Field: PayloadHeader.Version
Value: 0x200 -
551,2: Processing Field: PayloadHeader.HeaderLength
Value: 166 (0xA6)
551,3: Processing Field: PayloadHeader.Type
Value: Re-assembled
551,4: Processing Field: PayloadHeader.ReassembledProtocol
Value: TCP
551,5: Processing Field: PayloadHeader.RStatus
Value: Complete successfully (0)
551,6: Processing Field: PayloadHeader.LowerProtocolCount
Value: 2 (0x2)
551,7: Processing Field: PayloadHeader.LowerProtocol
Value: IPv4
551,8: Processing Field: PayloadHeader.LowerProtocol.ProtocolName
Value: IPv4
551,9: Processing Field: PayloadHeader.LowerProtocol.ConversationKeyLength
Value: 8 (0x8)
551,10: Processing Field: PayloadHeader.LowerProtocol.ConversationKey
Value:
551,11: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 76 (0x4C)
551,12: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 159 (0x9F)
551,13: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 220 (0xDC)
551,14: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 147 (0x93)
551,15: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 128 (0x80)
551,16: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 159 (0x9F)
551,17: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 220 (0xDC)
551,18: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 147 (0x93)
551,19: Processing Field: PayloadHeader.LowerProtocol.PropertyBlockLength
Value: 12 (0xC)
551,20: Processing Field: PayloadHeader.LowerProtocol.IPv4Properties
Value: Source Address = 147.220.159.128, Destination Address = 147.220.159.76
551,21: Processing Field: PayloadHeader.LowerProtocol.IPv4Properties.SourceAddressDescriptor
Value: Not cumulative, number big endian, Length given:4 bytes
551,22: Processing Field: PayloadHeader.LowerProtocol.IPv4Properties.SourceAddress
Value: 147.220.159.128
Repurposing Source IP Address: 147.220.159.128
551,23: Processing Field: PayloadHeader.LowerProtocol.IPv4Properties.DestinationAddressDescriptor
Value: Not cumulative, number big endian, Length given:4 bytes
551,24: Processing Field: PayloadHeader.LowerProtocol.IPv4Properties.DestinationAddress
Value: 147.220.159.76
Repurposing Destination IP Address 147.220.159.76
551,25: Processing Field: PayloadHeader.LowerProtocol
Value: TCP
551,26: Processing Field: PayloadHeader.LowerProtocol.ProtocolName
Value: TCP
551,27: Processing Field: PayloadHeader.LowerProtocol.ConversationKeyLength
Value: 4 (0x4)
551,28: Processing Field: PayloadHeader.LowerProtocol.ConversationKey
Value:
551,29: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 104 (0x68)
551,30: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 5 (0x5)
551,31: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 124 (0x7C)
551,32: Processing Field: PayloadHeader.LowerProtocol.ConversationKey.ConversationKey
Value: 2 (0x2)
551,33: Processing Field: PayloadHeader.LowerProtocol.PropertyBlockLength
Value: 50 (0x32)
551,34: Processing Field: PayloadHeader.LowerProtocol.TCPProperties
Value:
551,35: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.SourcePortDescriptor
Value: Not cumulative, number big endian
551,36: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.SourcePort
Value: 636 (0x27C)
Using Source Port: 8935704610656485376
551,37: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.DestinationPortDescriptor
Value: Not cumulative, number big endian
551,38: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.DestinationPort
Value: 1384 (0x568)
Using Destination Port: 7495397154828058624
551,39: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.SeqNumberDescriptor
Value: Not cumulative, number big endian
551,40: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.SeqNumber
Value: 2059249701 (0x7ABDA825)
551,41: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.NextSeqNumberDescriptor
Value: Not cumulative, number big endian, Update with the latest
551,42: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.NextSeqNumber
Value: 2059251664 (0x7ABDAFD0)
551,43: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.TcpFlagsDescriptor
Value: Not cumulative, number big endian, Update with the latest
551,44: Processing Field: PayloadHeader.LowerProtocol.TCPProperties.TcpFlags
Value: 24 (0x18)
551,45: Processing Field: PayloadHeader.FrameCount
Value: 2 (0x2)
551,46: Processing Field: PayloadHeader.PayloadLength
Value: 1963 (0x7AB)
551,47: Processing Field: PayloadHeader.ContainedProtocol
Value:
551,48: Processing Field: PayloadHeader.TLSSSLData
Value: Transport Layer Security (TLS) Payload Data
551,49: Processing Field: PayloadHeader.TLSSSLData.TLS
Value: TLS Rec Layer-1 HandShake: Server Hello. Certificate. Certificate Request. Server Hello Done.
551,50: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer
Value:
551,51: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer
Value: TLS Rec Layer-1 HandShake:
551,52: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.ContentType
Value: HandShake:
Found Content Type: 22 (PayloadHeader.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.ContentType)
551,53: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version
Value: TLS 1.0
551,54: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Major
Value: 3 (0x3)
551,55: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Minor
Value: 1 (0x1)
551,56: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Length
Value: 1958 (0x7A6)
551,57: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake
Value: SSL HandShake Server Hello Done(0x0E)
551,58: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake
Value:
551,59: Processing Field: PayloadHeader.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType
Value: ServerHello(0x02)
Found Handshake Message 2 (PayloadHeader.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType)
EXCEPTION: Simultaneous ClientHello message present
No Frames were decrypted, Netmon Filter Set may not match with current parser version. Use parser version 3.4.2345.1 or greater.

-.-.-.-.-.-.- SSL Decryption Log Ends-.-.-.-.-.-.-

I'll gladly supply more info if needed.

New Post: EXCEPTION: Simultaneous ClientHello message present

BrianWhy — Tue, 11 Sep 2012 13:39:28 GMT

Trying to use NMDecrypt to decrypt LDAP/S traffic from a Win7 client to a Win2008R1 SP2 Active Directory domain controller, but the decryption always fails with EXCEPTION: Simultaneous ClientHello message present. Happens in multiple captures. Have selected the TCP conversation in the Network Conversations field. Using NMDecrypt 2.3.4 from CodePlex and have used both the Default and Windows parsers 3.4.2774.001.

From debug log file:

6,74: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake
Value:
6,75: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType
Value: ServerHello(0x02)
Found Handshake Message 2 (Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType)
EXCEPTION: Simultaneous ClientHello message present
No Frames were decrypted, Netmon Filter Set may not match with current parser version. Use parser version 3.4.2345.1 or greater.

From the network capture:

2 10:45:45 AM 9/7/2012 0.0000000  169.172.16.74 10.40.38.79 TCP TCP:Flags=......S., SrcPort=58447, DstPort=ldap protocol over TLS/SSL (was sldap)(636), PayloadLen=0, Seq=2920459848, Ack=0, Win=65535 ( Negotiating scale factor 0x1 ) = 65535 {TCP:2, IPv4:1}
3 10:45:45 AM 9/7/2012 0.0001559  10.40.38.79 169.172.16.74 TCP TCP: [Bad CheckSum]Flags=...A..S., SrcPort=ldap protocol over TLS/SSL (was sldap)(636), DstPort=58447, PayloadLen=0, Seq=1588180437, Ack=2920459849, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152 {TCP:2, IPv4:1}
4 10:45:45 AM 9/7/2012 0.0041307  169.172.16.74 10.40.38.79 TCP TCP:Flags=...A...., SrcPort=58447, DstPort=ldap protocol over TLS/SSL (was sldap)(636), PayloadLen=0, Seq=2920459849, Ack=1588180438, Win=33312 (scale factor 0x1) = 66624 {TCP:2, IPv4:1}
5 10:45:45 AM 9/7/2012 0.0046922  169.172.16.74 10.40.38.79 SSL SSL:SSLv2RecordLayer, ClientHello (0x01) {SSL:4, SSLVersionSelector:3, TCP:2, IPv4:1}
6 10:45:45 AM 9/7/2012 0.0263000  10.40.38.79 169.172.16.74 TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Certificate Request. Server Hello Done. {TLS:5, SSLVersionSelector:3, TCP:2, IPv4:1}
7 10:45:45 AM 9/7/2012 0.0319092  169.172.16.74 10.40.38.79 TCP TCP:Flags=...A...., SrcPort=58447, DstPort=ldap protocol over TLS/SSL (was sldap)(636), PayloadLen=0, Seq=2920459991, Ack=1588182724, Win=32863 (scale factor 0x1) = 65726 {TCP:2, IPv4:1}
8 10:45:45 AM 9/7/2012 0.0327988  169.172.16.74 10.40.38.79 TLS TLS:TLS Rec Layer-1 HandShake: Certificate.; TLS Rec Layer-2 HandShake: Client Key Exchange.; TLS Rec Layer-3 Cipher Change Spec; TLS Rec Layer-4 HandShake: Encrypted Handshake Message. {TLS:5, SSLVersionSelector:3, TCP:2, IPv4:1}
9 10:45:45 AM 9/7/2012 0.0342511  10.40.38.79 169.172.16.74 TLS TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TLS:5, SSLVersionSelector:3, TCP:2, IPv4:1}
10 10:45:45 AM 9/7/2012 0.0385734  169.172.16.74 10.40.38.79 LDAP LDAP:Encrypted Over SSL {LDAP:6, TLS:5, SSLVersionSelector:3, TCP:2, IPv4:1}
11 10:45:45 AM 9/7/2012 0.0459465  10.40.38.79 169.172.16.74 LDAP LDAP:Encrypted Over SSL {LDAP:6, TLS:5, SSLVersionSelector:3, TCP:2, IPv4:1}

Ideas?

BrianY MCT, MCLC

New Post: Missing client hello

probich0 — Wed, 25 Jul 2012 14:15:54 GMT

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.

Cheers,
-Paul

New Post: Missing client hello

PaulLong — Wed, 25 Jul 2012 13:54:56 GMT

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

Paul

New Post: Missing client hello

probich0 — Wed, 25 Jul 2012 13:31:58 GMT

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…

New Post: Missing client hello

probich0 — Wed, 25 Jul 2012 12:40:17 GMT

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

Stopped w3svc on the app server.
Tested the publishing rule on TMG. As expected, the test failed both to 8080 and 4443.
Started a trace on the app server.
Started w3svc on the app server.
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.

New Post: Missing client hello

PaulLong — Tue, 24 Jul 2012 17:38:44 GMT

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.

Thanks,

Paul

New Post: Missing client hello

probich0 — Tue, 24 Jul 2012 17:29:32 GMT

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:

Start the trace
Log in with the client app and do some stuff.
Stop the trace
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.

New Post: NMDecrypt not working.

SteveRoss — Tue, 17 Jul 2012 20:52:27 GMT

Dan,

In May, Paul gave me a workaround for the problem introduced by my "freerdp" client. In case you have the same problem here's the workaround. He wrote:

So there turns out to be an extra byte at the end of frame 8. We detect this as TLS fragmentation, which causes us to wait for the full segment. And this in turn screws up the expert.

If I remove the byte at the end with netmon, saved the capture, and the expert gets further and seems to work fine. Not sure if this is a viable work around or not for you (manually editing the cap file).

and

To edit the file, you can deselect Hex Edit Readonly under the Edit menu (Ctrl+R). Then you add or remove bytes in the hex view. You can save the resulting trace with your changes which I think is necessary for the expert to run.

I followed his instructions to remove an extra byte of 0x00 at the end of the "TLS Rec Layer-1 HandShake:Client Hello" frame. After this edit in NetMon, NMDecrypt successfully decrypted my capture file.

-- Steve Ross

New Post: NMDecrypt not working.

PaulLong — Mon, 16 Jul 2012 14:30:59 GMT

Having the full log would be a great start. Also the unencrypted trace would probably also help.

Dan can you contact me from the blog, http://blogs.technet.com and then you can send your data to me via email?

Thanks,

Paul

New Post: NMDecrypt not working.

DanPeterson — Fri, 13 Jul 2012 20:58:37 GMT

My NetMon version info:

Microsoft Network Monitor 3.4 (Version 3.4.2350.0)

Network Monitor Parsers: 03.04.2774.0001

Dan

New Post: NMDecrypt not working.

DanPeterson — Fri, 13 Jul 2012 20:54:26 GMT

I just encountered this same problem. I could be doing something wrong, but I don't think so. I get the following error no matter what I try:

...

Found Handshake Message 2 (Ethernet.Ipv4.Tcp.TCPPayload.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType)

EXCEPTION: Simultaneous ClientHello message present

No Frames were decrypted, Netmon Filter Set may not match with current parser version. Use parser version 3.4.2345.1 or greater.

-.-.-.-.-.-.- SSL Decryption Log Ends-.-.-.-.-.-.-

I have the conversation selected correctly. I have ClientHello, ServerHello, and Handshake messages in my selected conversation.

I am happy to send in the debug, the capture, and the PFX file to help debug the problem.

Dan

New Post: Hostotosto

Hostotosto — Mon, 04 Jun 2012 21:12:06 GMT

Thanks,

Hostotosto