I'm trying to decrypt TLS conversations using NetMon. I'm using x86 versions of NetMon 3.4 and x86 versions NMDecrypt ver. 2.3 and Parsers (latest) version 3.4.2748. It doesn't matter at all which parser I use, I get two errors. I'll note though, that when I installed the parsers, I upgraded from the parsers that were installed with Netmon 3.4 (I believe the version was 3.4.2345.

"No Fames were decrypted, Netmon Filter Set may not match with current parser version. Use parser version 3.4.2345.1"
or
Can't find SSL fames (after downgrading the parser).

I'm having a really hard time with this...can someone help? It doesn't seem that any parser version helps me at all. If the frames are correctly showing as TLS, than I always get the first error. If the frames show SSL instead of TLS, than I get the second error. I've tried about 4 different parsers, and am starting to think that this is a NMDecrypt issue or platform issue (x86 as opposed to x64 maybe?). Either way, I really need to get this working somehow. Thanks for your time...

Oh, one thing to note as well. I've tried this on an x86 Windows 7 machine and also an x86 Windows 2003 P2 Server machine.

Are you selecting the TCP conversation in the UI before launching the expert? 

Can you attach the log file?

Thanks,

Paul

Paul,

Thanks for the quick response. Yes, I selected the conversation that I wanted to decrypt in several ways (just in case I was missing something). Seems pretty straight forward though, honestly.

How can I get the file to you? Any other method than posting directly on the discussion page? Not only that, but I've tried so many versions. I have yet to see someone say that NetMon version 3.4 works with NMDecrypt version 2.3 and parsers version X.XX.XXXX directly. Again, thanks for your help. Here's a little snippet of the , which you may find useful.

Only Network Monitor version 3.4.2350.0 is available from Microsoft, so am I stuck with this problem until it's resolved?

==========================================

****Warning****: Using a non TCP Conversation Filter, Conversation.IPv4.Id == 1, might cause the expert to fail.  You should use a filter at the TCP layer or higher.  A conversation filter at a higher level might work, say IPv4 or IPv6, but this depends on the traffic.  Under these conditions all traffic must use the same certificate and the traffic for each conversation must be sequential.
Conversation Filter, Conversation.IPv4.Id == 1 added successfully
SSL Version Filter added successfully
Adding Conversation.IPv4.Id == 1 Conversation Filter...
****Warning****: Using a non TCP Conversation Filter, Conversation.IPv4.Id == 1, might cause the expert to fail.  You must use a filter at the TCP layer or higher.  A conversation filter at a higher level might work, say IPv4 or IPv6, but this depends on the traffic.  Under these conditions all traffic must use the same certificate and the traffic for each conversation must be sequential.
Eval Parser Conversation Filter, Conversation.IPv4.Id == 1 added successfully
****Warning****: Network Monitor  Version: 3.4.2350.0 may cause Expert to fail.  Please use 3.4.2345.1 or greater.
****Warning***: We've tested with version: 03.04.2590.0001.  Your version is: 03.04.2748.0001 0000 This might cause problems if the TLS/SSL parsers have changed significantly

==========================================

Hope that helps!

In the example above you selected the IPv4 conversation rather than the TCP one.  It's possible this is causing a problem and sometimes multiple TLS/SSL conversations can confuse the expert.  I would try selecting a single TCP conversation.  Before running the expert, makes sure the full TLS/SSL conversation exists.  You should see a TCP 3-way handshak followed by a TLS/SSL Client Hello/Server Hello (as decribed in the documentation).  The client hello should not reuse the session ID, which means that the SessionIDLength needs to be equal to zero for the expert to work.

Hopefully given these parameters, you should be able to get the expert to work and decrypt traffic.  If you are still stuck, just send the first few lines, and the last few lines.  If you want to share the entire log, you could do this via SkyDrive or some other similar service.

Paul

Yeah, makes sense although I still get the same error. I've tried decrypting just the TCP session as well. Like I said, I've tried a lot of various ways in case I was missing something. Here's the output of the new (TCP) log file:

-.-.-.-.-.-.- SSL Decryption Log -.-.-.-.-.-.-
Log Created On: 12/13/2011 12:28:16 PM
NMAPIs Initialized.
Initializing Netmon Parsers...
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Documents and Settings\All Users\Application Data\Microsoft\Network Monitor 3\NPL\NetworkMonitor Parsers\Profiles\FE3524BB-D1B3-41a4-BA6B-B05C3056B4D7\sparser.npb.
Netmon Parsers initialized successfully.
Adding SSLVersionSelector Display Filter...
Display Filter added successfully
Adding Conversation.TCP.Id == 2 Conversation Filter...
Conversation Filter, Conversation.TCP.Id == 2 added successfully
SSL Version Filter added successfully
Adding Conversation.TCP.Id == 2 Conversation Filter...
Eval Parser Conversation Filter, Conversation.TCP.Id == 2 added successfully
****Warning****: Network Monitor  Version: 3.4.2350.0 may cause Expert to fail.  Please use 3.4.2345.1 or greater.
****Warning***: We've tested with version: 03.04.2590.0001.  Your version is: 03.04.2748.0001 0000 This might cause problems if the TLS/SSL parsers have changed significantly
Opening Encrypted Capture File: C:\Documents and Settings\Administrator\Desktop\tls_session.pcap
Creating Decrypted Capture File: C:\Documents and Settings\Administrator\Desktop\decrypted_test5.cap
Using Init Filter String of Ethernet.Ipv4.Tcp.TCPPayload.TlsSslData.Tls.
Changing Conversation ID from 18446744073709551615 to 2
.................................................
IsTLSSLPayloadFragmented: Frame 11
.................................................

(cont...)

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-.-.-.-.-.-.-

Any ideas? This is one conversation from mail client A > mail server B.

I'm looking a little more, and it appears that packet 12-14 are one single packet (continuation of 12), and this behavior occurs several times. I'm using "tcpdump -s 0" when capturing to a file with the "-w" flag (this is on a Linux machine). I thought that should reduce packet truncation, correct? Even still, I see an option for "Reassembly" in NetMon, however when I use this function...Experts is not available, and I still see packet continuation throughout the capture. Any ideas? Again...I really appreciate your help!

Brandon

The TCP Dump operation seems OK.  The message can be fragmented and the expert can handle that.  However, there might be situations where this doesn't work I guess.

Based on the log output above, it complaining that it sees two client hello messages.  Can you in netmon, select the conversation, highlight the first 10 frames, press Ctrl+C, and copy them into the forum thread?  That way I think I should be able to understand the traffic you are trying to decrypt and see if anything pops out.

Paul

Here you go...

1 4:05:35 PM 12/8/2011 0.0000000 74.125.82.52 10.7.30.105 TCP TCP:Flags=......S., SrcPort=41265, DstPort=SMTP(25), PayloadLen=0, Seq=118859307, Ack=0, Win=5720 ( Negotiating scale factor 0x6 ) = 5720
2 4:05:35 PM 12/8/2011 0.0002100 10.7.30.105 74.125.82.52 TCP TCP:Flags=...A..S., SrcPort=SMTP(25), DstPort=41265, PayloadLen=0, Seq=3161332436, Ack=118859308, Win=5792 ( Scale factor not supported ) = 5792
3 4:05:35 PM 12/8/2011 0.1099950 74.125.82.52 10.7.30.105 TCP TCP:Flags=...A...., SrcPort=41265, DstPort=SMTP(25), PayloadLen=0, Seq=118859308, Ack=3161332437, Win=5720 (scale factor 0x0) = 5720
4 4:05:35 PM 12/8/2011 0.1116680 10.7.30.105 74.125.82.52 SMTP SMTP:Rsp 220  mssib01.avms-mss-01c-02vh.ncsportbike.com ESSCAN/SMTP Ready., 66 bytes
5 4:05:35 PM 12/8/2011 0.2238200 74.125.82.52 10.7.30.105 TCP TCP:Flags=...A...., SrcPort=41265, DstPort=SMTP(25), PayloadLen=0, Seq=118859308, Ack=3161332503, Win=5720 (scale factor 0x0) = 5720
6 4:05:35 PM 12/8/2011 0.2240180 74.125.82.52 10.7.30.105 SMTP SMTP:Cmd EHLO mail-ww0-f52.google.com, 30 bytes
7 4:05:35 PM 12/8/2011 0.2241770 10.7.30.105 74.125.82.52 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=41265, PayloadLen=0, Seq=3161332503, Ack=118859338, Win=5792 (scale factor 0x0) = 5792
8 4:05:35 PM 12/8/2011 0.2255060 10.7.30.105 74.125.82.52 SMTP SMTP:Rsp 250 -Requested mail action okay, completed., 58 bytes
9 4:05:35 PM 12/8/2011 0.3376450 74.125.82.52 10.7.30.105 SMTP SMTP:Cmd STARTTLS, Server is currently able to negotiate the use of TLS
10 4:05:35 PM 12/8/2011 0.3387000 10.7.30.105 74.125.82.52 SMTP SMTP:Rsp 220  Start TLS negotiation., 28 bytes
11 4:05:35 PM 12/8/2011 0.4492820 74.125.82.52 10.7.30.105 TLS TLS:Continued Data: 69 Bytes
12 4:05:35 PM 12/8/2011 0.4496170 10.7.30.105 74.125.82.52 TLS TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.
13 4:05:35 PM 12/8/2011 0.4496300 10.7.30.105 74.125.82.52 TCP TCP:[Continuation to #12]Flags=...A...., SrcPort=SMTP(25), DstPort=41265, PayloadLen=1368, Seq=3161333957 - 3161335325, Ack=118859417, Win=5792 (scale factor 0x0) = 5792
14 4:05:35 PM 12/8/2011 0.4496370 10.7.30.105 74.125.82.52 TCP TCP:[Continuation to #12]Flags=...AP..., SrcPort=SMTP(25), DstPort=41265, PayloadLen=1360, Seq=3161335325 - 3161336685, Ack=118859417, Win=5792 (scale factor 0x0) = 5792

Hmm, I suppose I wasn't expecting a SMTP setup with TLS riding ontop, but it does seem to parse properly. I need to dig into the data further to understand if this is a scenario the expert hasn't encountered before.  At this point I need to see the entire log and if possible the capture file. 

You can share the files by using something like skydrive.  Skydrive is actually down for me, but perhaps you are aware of another similar file sharing system.

Alternatively, you can start a thread by emailing the author on my blog at http://blogs.technet.com/netmon.  Just include your real email address, then I can respond with mine and we'll be able to pass files and continue our discussion over email.

Paul

Was this problem ever resolved?  If so, how?

I'm seeing the same error as mentioned previously, namely

--------------------------

59,76: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandShake.HandShake.HandShakeType Value: ServerHello(0x02)

Found Handshake Message 2 (Ethernet.Ipv4.Tcp.TCPPayload.RDP.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.

---------------------------

This occurs on three capture files that I collected today.  In all three files, the same decryption error occurs when NmDecrypt is operating on the line

TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done

I'm using:

• Network Monitor 3.4.2350 (dated 24 June 2010)
• the open-source parser package, version 3.4.2774.0001 (dated 19 Dec 2011)
• NmDecrypt 2.3.3 (dated 26 October 2011)

to decrypt TLS/SSL traffic.  I've caught the initial TLS/SSL handshake in the network traffic.  My Parser Profile is set to "Windows".  I have selected the TCP conversation that includes the "Client Hello/Server Hello/Client Key Exchange" set of three packets.

-- Steve Ross

One additional tidbit of information in regards to my last post....

My last successful decryption used "mstsc.exe" as the client on the front-end machine.  All of the three failures that I mentioned above are with a "FreeRDP" client on the front-end machine.

Yes, this was due to a bug in how the path was remembered.  The source code has been udpated, but not the executable.  I will try to get a new version up there soon.  In the mean time, if you have the means you can build the project.

Paul

Paul,

Thanks for your reply.  Unless it will take you days to build, I'm sure that you could do it faster than I could figure out how to do it.

In the meantime, is there any procedure that I can follow to avoid/workaround the problem?

Thanks,

-- Steve Ross

The original issue, if I remember, is that the stack would change.  The path to each field would start off with one pattern and then switch after a few frames.  So I don't beleive you could change this pattern as it's part of the protocol.

I will try to update the expert tomorrow.

Paul

Thanks, I'll look forward to trying it out. -- Steve

OK, it's been updated to 2.3.4 now. 

Thanks very much for building it.

The version at <http://nmdecrypt.codeplex.com/> still seems to be 2.3.3 with a signing date of 25 October 2011.  Where should I look for version 2.3.4?

Thanks,

-- Steve

Oops, forgot to make it visible.  Please check now.

Paul

Hmm, unfortunately, I'm getting the same exception using NmDecrypt 2.3.4.

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.

-- Steve

Bummer.  Can you send me the new log?  Hopefully that will tell me what is going on.

Paul

Paul,

Following is the log of the one of the decryptions. In my three logs from three different captures, NmDecrypt stops on the same line in each, namely

 TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done.

This decryption was attempted with NmDecrypt version 2.3.4 (i.e, the "NetmonDecryptionExpert.exe" has a file version number of "2.3.4.0" although its last modified date is 3/1/2012 which seems too early,, I'd expect 4/5/2012).

I'm sorry that I 'm not allowed to provide the actual capture as well.

-- Steve Ross

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

Log Created On: 4/5/2012 5:45:05 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\FE3524BB-D1B3-41a4-BA6B-B05C3056B4D7\sparser.npb.
Netmon Parsers initialized successfully.
Adding SSLVersionSelector Display Filter...
Display Filter added successfully
Adding Conversation.TCP.Id == 31 Conversation Filter...
Conversation Filter, Conversation.TCP.Id == 31 added successfully
SSL Version Filter added successfully
Adding Conversation.TCP.Id == 31 Conversation Filter...
Eval Parser Conversation Filter, Conversation.TCP.Id == 31 added successfully
This Netmon Version is supported
****Warning***: We've tested with version: 03.04.2748.0001.  Your version is: 03.04.2774.0001 0000. This might cause problems if the TLS/SSL parsers have changed significantly.
Opening Encrypted Capture File: C:\Users\Administrator\Documents\Network Monitor 3\Captures\120403-sc1-pull-reinsert-card.cap
Creating Decrypted Capture File: C:\Users\Administrator\Documents\Network Monitor 3\Captures\120403-sc1-pull-reinsert-card.decrypt.cap
Proposing Init Filter String of Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData
Using Init Filter String of Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.Tls.
Changing Conversation ID from 18446744073709551615 to 31
.................................................
Entered IsTLSSLPayloadFragmented: Frame 72
.................................................

===========================================================================
Processing Frame Number: 72
===========================================================================
Found 1334 Fields in Frame
72,0: Processing Field: Ethernet
   Value: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-9B-A4-27],SourceAddress:[00-50-56-88-15-CD]
72,1: Processing Field: Ethernet.DestinationAddress
   Value: VMware, Inc. 9BA427 [00-0C-29-9B-A4-27]
Repurposing Destination IP Address VMware, Inc. 9BA427 [00-0C-29-9B-A4-27]
72,2: Processing Field: Ethernet.DestinationAddress.Rsv
   Value: (000000..)
72,3: Processing Field: Ethernet.DestinationAddress.UL
   Value:  (......0.) Universally Administered Address
72,4: Processing Field: Ethernet.DestinationAddress.IG
   Value:  (.......0) Individual address (unicast)
72,5: Processing Field: Ethernet.SourceAddress
   Value: VMWare, Inc. 8815CD [00-50-56-88-15-CD]
Repurposing Source IP Address: VMWare, Inc. 8815CD [00-50-56-88-15-CD]
72,6: Processing Field: Ethernet.SourceAddress.Rsv
   Value: (000000..)
72,7: Processing Field: Ethernet.SourceAddress.UL
   Value:  (......0.) Universally Administered Address
72,8: Processing Field: Ethernet.SourceAddress.IG
   Value:  (.......0) Individual address (unicast)
72,9: Processing Field: Ethernet.EthernetType
   Value: Internet IP (IPv4), 2048(0x800)
72,10: Processing Field: Ethernet.Ipv4
   Value: Src = 10.1.2.0, Dest = 10.1.1.126, Next Protocol = TCP, Packet ID = 24938, Total IP Length = 940
72,11: Processing Field: Ethernet.Ipv4.Versions
   Value: IPv4, Internet Protocol; Header Length = 20
72,12: Processing Field: Ethernet.Ipv4.Versions.Version
   Value:      (0100....) IPv4, Internet Protocol
72,13: Processing Field: Ethernet.Ipv4.Versions.HeaderLength
   Value: (....0101) 20 bytes (0x5)
72,14: Processing Field: Ethernet.Ipv4.DifferentiatedServicesField
   Value: DSCP: 0, ECN: 0
72,15: Processing Field: Ethernet.Ipv4.DifferentiatedServicesField.DSCP
   Value: (000000..) Differentiated services codepoint 0
72,16: Processing Field: Ethernet.Ipv4.DifferentiatedServicesField.ECT
   Value:  (......0.) ECN-Capable Transport not set
72,17: Processing Field: Ethernet.Ipv4.DifferentiatedServicesField.CE
   Value:   (.......0) ECN-CE not set
72,18: Processing Field: Ethernet.Ipv4.TotalLength
   Value: 940 (0x3AC)
72,19: Processing Field: Ethernet.Ipv4.Identification
   Value: 24938 (0x616A)
72,20: Processing Field: Ethernet.Ipv4.FragmentFlags
   Value: 16384 (0x4000)
72,21: Processing Field: Ethernet.Ipv4.FragmentFlags.Reserved
   Value: (0...............)
72,22: Processing Field: Ethernet.Ipv4.FragmentFlags.DF
   Value:       (.1..............) Do not fragment
72,23: Processing Field: Ethernet.Ipv4.FragmentFlags.MF
   Value:       (..0.............) This is the last fragment
72,24: Processing Field: Ethernet.Ipv4.FragmentFlags.Offset
   Value:   (...0000000000000) 0
72,25: Processing Field: Ethernet.Ipv4.TimeToLive
   Value: 128 (0x80)
72,26: Processing Field: Ethernet.Ipv4.NextProtocol
   Value: TCP, 6(0x6)
72,27: Processing Field: Ethernet.Ipv4.Checksum
   Value: 0 (0x0)
72,28: Processing Field: Ethernet.Ipv4.SourceAddress
   Value: 10.1.2.0
Repurposing Source IP Address: 10.1.2.0
72,29: Processing Field: Ethernet.Ipv4.DestinationAddress
   Value: 10.1.1.126
Repurposing Destination IP Address 10.1.1.126
72,30: Processing Field: Ethernet.Ipv4.Options
   Value:
72,31: Processing Field: Ethernet.Ipv4.Tcp
   Value: Flags=...AP..., SrcPort=MS WBT Server(3389), DstPort=52226, PayloadLen=888, Seq=485295798 - 485296686, Ack=2255471315, Win=259 (scale factor 0x8) = 66304
72,32: Processing Field: Ethernet.Ipv4.Tcp.SrcPort
   Value: MS WBT Server(3389)
Using Source Port: 3389
72,33: Processing Field: Ethernet.Ipv4.Tcp.DstPort
   Value: 52226
Using Destination Port: 52226
72,34: Processing Field: Ethernet.Ipv4.Tcp.SequenceNumber
   Value: 485295798 (0x1CED06B6)
72,35: Processing Field: Ethernet.Ipv4.Tcp.AcknowledgementNumber
   Value: 2255471315 (0x866FC2D3)
72,36: Processing Field: Ethernet.Ipv4.Tcp.DataOffset
   Value: 128 (0x80)
72,37: Processing Field: Ethernet.Ipv4.Tcp.DataOffset.DataOffset
   Value: (1000....) 32 bytes
72,38: Processing Field: Ethernet.Ipv4.Tcp.DataOffset.Reserved
   Value:   (....000.)
72,39: Processing Field: Ethernet.Ipv4.Tcp.DataOffset.NS
   Value:         (.......0) Nonce Sum not significant
72,40: Processing Field: Ethernet.Ipv4.Tcp.Flags
   Value: ...AP...
72,41: Processing Field: Ethernet.Ipv4.Tcp.Flags.CWR
   Value:    (0.......) CWR not significant
72,42: Processing Field: Ethernet.Ipv4.Tcp.Flags.ECE
   Value:    (.0......) ECN-Echo not significant
72,43: Processing Field: Ethernet.Ipv4.Tcp.Flags.Urgent
   Value: (..0.....) Not Urgent Data
72,44: Processing Field: Ethernet.Ipv4.Tcp.Flags.Ack
   Value:    (...1....) Acknowledgement field significant
72,45: Processing Field: Ethernet.Ipv4.Tcp.Flags.Push
   Value:   (....1...) Push Function
72,46: Processing Field: Ethernet.Ipv4.Tcp.Flags.Reset
   Value:  (.....0..) No Reset
72,47: Processing Field: Ethernet.Ipv4.Tcp.Flags.Syn
   Value:    (......0.) Not Synchronize sequence numbers
72,48: Processing Field: Ethernet.Ipv4.Tcp.Flags.Fin
   Value:    (.......0) Not End of data
72,49: Processing Field: Ethernet.Ipv4.Tcp.Window
   Value: 259 (scale factor 0x8) = 66304
72,50: Processing Field: Ethernet.Ipv4.Tcp.Checksum
   Value: 0x1B1E, Disregarded
72,51: Processing Field: Ethernet.Ipv4.Tcp.UrgentPointer
   Value: 0 (0x0)
72,52: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions
   Value:
72,53: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option
   Value:
72,54: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.NoOption
   Value:
72,55: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.NoOption.type
   Value: No operation. 1(0x1)
72,56: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.NoOption
   Value:
72,57: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.NoOption.type
   Value: No operation. 1(0x1)
72,58: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.TimeStamp
   Value:
72,59: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.TimeStamp.type
   Value: Timestamp. 8(0x8)
72,60: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.TimeStamp.Length
   Value: 10 (0xA)
72,61: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.TimeStamp.TimestampValue
   Value: 6663977 (0x65AF29)
72,62: Processing Field: Ethernet.Ipv4.Tcp.TCPOptions.Option.TimeStamp.TimestampEchoReply
   Value: 66220250 (0x3F270DA)
72,63: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload
   Value: SourcePort = 3389, DestinationPort = 52226
72,64: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP
   Value: SSL
72,65: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData
   Value: Transport Layer Security (TLS) Payload Data
72,66: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS
   Value: TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done.
72,67: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer
   Value:
72,68: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer
   Value: TLS Rec Layer-1 HandShake:
72,69: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.ContentType
   Value: HandShake:
Found Content Type: 22 (Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.Tls.TlsRecLayer.TlsRecordLayer.ContentType)
72,70: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version
   Value: TLS 1.0
72,71: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Major
   Value: 3 (0x3)
72,72: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Version.Minor
   Value: 1 (0x1)
72,73: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.Length
   Value: 883 (0x373)
72,74: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake
   Value: SSL HandShake Server Hello Done(0x0E)
72,75: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake
   Value:
72,76: Processing Field: Ethernet.Ipv4.Tcp.TCPPayload.RDP.TLSSSLData.TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType
   Value: ServerHello(0x02)
Found Handshake Message 2 (Ethernet.Ipv4.Tcp.TCPPayload.RDP.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-.-.-.-.-.-.-

Normally TLS data starts with a ClientHello and this looks like the ServerHello.  Do you see a client hello in the trace?  Is frame 72 the first TLS frame in the conversation?

Hi Paul,

This capture does include a "Client Hello" ahead of the "Server Hello".  Frame #71 is the first TLS frame in the conversation. Here are the frames in the neighborhood of frame #72.  The fields shown are:

Frame Number, Process Name, Source, Destination, Protocol Name, Description, Conv Id

The frames are:

71 svchost.exe client-IP server-IP TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
72 svchost.exe server-IP client-IP TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
73 svchost.exe client-IP server-IP  TLS TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
74 svchost.exe server-IP client-IP TLS TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}

Thanks for your on-going help,

-- Steve Ross

It's very strange that the log doesn't start with frame 71.  Does the traffic include the TCP 3-way handshake?  When the conversation is selected, does it UI include 71?

Assuming all the above is true, can you copy and paste the details tree from frame 71?

Paul

Hi Paul,

The conversation does include a bit of TCP traffic ahead of the TLS client-server handshake.  This same conversation also includes frame #71.

There are two sets of information below.  The first part is a copy of the frame summary for the first 12 frames of the conversation (which includes both #71 and #72).  The second set of info is the expansion of the details tree that you requested.

-- Steve

---- begin first 12 packets of TCP conversation ---

62 15.1474161 svchost.exe 10.1.1.126 10.1.2.0 TCP TCP:Flags=......S., SrcPort=52226, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=2255471206, Ack=0, Win=5840 ( Negotiating scale factor 0x4 ) = 5840 {TCP:31, IPv4:30}
65 15.1484130 svchost.exe 10.1.2.0 10.1.1.126 TCP TCP:Flags=...A..S., SrcPort=MS WBT Server(3389), DstPort=52226, PayloadLen=0, Seq=485295778, Ack=2255471207, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152 {TCP:31, IPv4:30}
66 15.1494945 svchost.exe 10.1.1.126 10.1.2.0 TCP TCP:Flags=...A...., SrcPort=52226, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=2255471207, Ack=485295779, Win=365 (scale factor 0x4) = 5840 {TCP:31, IPv4:30}
67 15.1495563 svchost.exe 10.1.1.126 10.1.2.0 X224 X224:Connection Request {ISOTS:32, TCP:31, IPv4:30}
68 15.1543984 svchost.exe 10.1.2.0 10.1.1.126 TCP TCP:Flags=...A...., SrcPort=MS WBT Server(3389), DstPort=52226, PayloadLen=0, Seq=485295779, Ack=2255471226, Win=260 (scale factor 0x8) = 66560 {TCP:31, IPv4:30}
69 15.1545439 svchost.exe 10.1.2.0 10.1.1.126 X224 X224:Connection Confirm {ISOTS:32, TCP:31, IPv4:30}
70 15.1556045 svchost.exe 10.1.1.126 10.1.2.0 TCP TCP:Flags=...A...., SrcPort=52226, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=2255471226, Ack=485295798, Win=365 (scale factor 0x4) = 5840 {TCP:31, IPv4:30}
71 15.1586798 svchost.exe 10.1.1.126 10.1.2.0 TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
72 15.1588375 svchost.exe 10.1.2.0 10.1.1.126 TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
73 15.1614476 svchost.exe 10.1.1.126 10.1.2.0 TLS TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
74 15.1626014 svchost.exe 10.1.2.0 10.1.1.126 TLS TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}
75 15.1641468 svchost.exe 10.1.1.126 10.1.2.0 TLS TLS:TLS Rec Layer-1 SSL Application Data {TLS:34, SSLVersionSelector:33, TCP:31, IPv4:30}

---- end first 12 packets of TCP conversation ---

---- begin frame details tree for Frame #71 ----

 Frame: Number = 71, Captured Frame Length = 155, MediaType = ETHERNET
- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-50-56-88-15-CD],SourceAddress:[00-0C-29-9B-A4-27]
  - DestinationAddress: VMWare, Inc. 8815CD [00-50-56-88-15-CD]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
  - SourceAddress: VMware, Inc. 9BA427 [00-0C-29-9B-A4-27]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
    EthernetType: Internet IP (IPv4), 2048(0x800)
- Ipv4: Src = 10.1.1.126, Dest = 10.1.2.0, Next Protocol = TCP, Packet ID = 45740, Total IP Length = 141
  - Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
  - DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT:  (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 141 (0x8D)
    Identification: 45740 (0xB2AC)
  - FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 63 (0x3F)
    NextProtocol: TCP, 6(0x6)
    Checksum: 28991 (0x713F)
    SourceAddress: 10.1.1.126
    DestinationAddress: 10.1.2.0
    UnparsedData: Binary Large Object (1 Bytes)
- Tcp: Flags=...AP..., SrcPort=52226, DstPort=MS WBT Server(3389), PayloadLen=89, Seq=2255471226 - 2255471315, Ack=485295798, Win=365 (scale factor 0x4) = 5840
    SrcPort: 52226
    DstPort: MS WBT Server(3389)
    SequenceNumber: 2255471226 (0x866FC27A)
    AcknowledgementNumber: 485295798 (0x1CED06B6)
  - DataOffset: 128 (0x80)
     DataOffset: (1000....) 32 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
  - Flags: ...AP...
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....1...) Push Function
     Reset:  (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 365 (scale factor 0x4) = 5840
    Checksum: 0x78BD, Good
    UrgentPointer: 0 (0x0)
  - TCPOptions: 
   - NoOption: 
      type: No operation. 1(0x1)
   - NoOption: 
      type: No operation. 1(0x1)
   - TimeStamp: 
      type: Timestamp. 8(0x8)
      Length: 10 (0xA)
      TimestampValue: 66220250 (0x3F270DA)
      TimestampEchoReply: 6663976 (0x65AF28)
  - TCPPayload: SourcePort = 52226, DestinationPort = 3389
     RDP: SSL
  TLSSSLData: Transport Layer Security (TLS) Payload Data
- TLS: TLS Rec Layer-1 HandShake: Client Hello.
  - TlsRecordLayer: TLS Rec Layer-1 HandShake:
     ContentType: HandShake:
   - Version: TLS 1.0
      Major: 3 (0x3)
      Minor: 1 (0x1)
     Length: 84 (0x54)
   - SSLHandshake: SSL HandShake ClientHello(0x01)
      HandShakeType: ClientHello(0x01)
      Length: 80 (0x50)
    - ClientHello: TLS 1.0
     - Version: TLS 1.0
        Major: 3 (0x3)
        Minor: 1 (0x1)
     - RandomBytes: 
        TimeStamp: 04/03/2012, 16:18:40 .0000 UTC 
        RandomBytes: Binary Large Object (28 Bytes)
       SessionIDLength: 0 (0x0)
       CipherSuitesLength: 40
     - TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA        { 0x00, 0x39 }
        Cipher: 57 (0x39)
     - TLSCipherSuites: TLS_DHE_DSS_WITH_AES_256_CBC_SHA        { 0x00, 0x38 }
        Cipher: 56 (0x38)
     - TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA            { 0x00, 0x35 }
        Cipher: 53 (0x35)
     - TLSCipherSuites: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       { 0x00, 0x16 }
        Cipher: 22 (0x16)
     - TLSCipherSuites: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       { 0x00, 0x13 }
        Cipher: 19 (0x13)
     - TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA           { 0x00, 0x0A }
        Cipher: 10 (0xA)
     - TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA        { 0x00, 0x33 }
        Cipher: 51 (0x33)
     - TLSCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA        { 0x00, 0x32 }
        Cipher: 50 (0x32)
     - TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA            { 0x00, 0x2F }
        Cipher: 47 (0x2F)
     - TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA                { 0x00, 0x05 }
        Cipher: 5 (0x5)
     - TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5                { 0x00, 0x04 }
        Cipher: 4 (0x4)
     - TLSCipherSuites: TLS_DHE_RSA_WITH_DES_CBC_SHA            { 0x00, 0x15 }
        Cipher: 21 (0x15)
     - TLSCipherSuites: TLS_DHE_DSS_WITH_DES_CBC_SHA            { 0x00, 0x12 }
        Cipher: 18 (0x12)
     - TLSCipherSuites: TLS_RSA_WITH_DES_CBC_SHA                { 0x00, 0x09 }
        Cipher: 9 (0x9)
     - TLSCipherSuites: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   { 0x00, 0x14 }
        Cipher: 20 (0x14)
     - TLSCipherSuites: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   { 0x00, 0x11 }
        Cipher: 17 (0x11)
     - TLSCipherSuites: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA       { 0x00, 0x08 }
        Cipher: 8 (0x8)
     - TLSCipherSuites: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5      { 0x00, 0x06 }
        Cipher: 6 (0x6)
     - TLSCipherSuites: TLS_RSA_EXPORT_WITH_RC4_40_MD5          { 0x00, 0x03 }
        Cipher: 3 (0x3)
     - TLSCipherSuites: TLS_EMPTY_RENEGOTIATION_INFO_SCSV       { 0x00, 0xFF }
        Cipher: 255 (0xFF)
       CompressionMethodsLength: 2 (0x2)
       CompressionMethods: 1 (0x1)

---- end frame details tree for Frame #71 ----

Hmm., the x224 before hand looks similiar to a problem I fixed, but perhaps this is a different variant.  Can you send me the unencrypted trace file?  You could even just save out that conversation (just Save As, Displayed).  If not I will have to study the code, which will take longer :)

Thanks,

Paul

Hi Paul,

I hope that the following will do.  They are the Frame Details for the X224 frames, the "Connection Request" followed by the "Connnection Confirm".

-- Steve

--- begin Frame Details tree for Frame #67, Connection Request ----

  Frame: Number = 67, Captured Frame Length = 85, MediaType = ETHERNET
- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-50-56-88-15-CD],SourceAddress:[00-0C-29-9B-A4-27]
  - DestinationAddress: VMWare, Inc. 8815CD [00-50-56-88-15-CD]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
  - SourceAddress: VMware, Inc. 9BA427 [00-0C-29-9B-A4-27]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
    EthernetType: Internet IP (IPv4), 2048(0x800)
- Ipv4: Src = 10.1.1.126, Dest = 10.1.2.0, Next Protocol = TCP, Packet ID = 45738, Total IP Length = 71
  - Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
  - DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT:  (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 71 (0x47)
    Identification: 45738 (0xB2AA)
  - FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 63 (0x3F)
    NextProtocol: TCP, 6(0x6)
    Checksum: 29063 (0x7187)
    SourceAddress: 10.1.1.126
    DestinationAddress: 10.1.2.0
- Tcp: Flags=...AP..., SrcPort=52226, DstPort=MS WBT Server(3389), PayloadLen=19, Seq=2255471207 - 2255471226, Ack=485295779, Win=365 (scale factor 0x4) = 5840
    SrcPort: 52226
    DstPort: MS WBT Server(3389)
    SequenceNumber: 2255471207 (0x866FC267)
    AcknowledgementNumber: 485295779 (0x1CED06A3)
  - DataOffset: 128 (0x80)
     DataOffset: (1000....) 32 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
  - Flags: ...AP...
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....1...) Push Function
     Reset:  (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 365 (scale factor 0x4) = 5840
    Checksum: 0xE1C1, Good
    UrgentPointer: 0 (0x0)
  - TCPOptions: 
   - NoOption: 
      type: No operation. 1(0x1)
   - NoOption: 
      type: No operation. 1(0x1)
   - TimeStamp: 
      type: Timestamp. 8(0x8)
      Length: 10 (0xA)
      TimestampValue: 66220241 (0x3F270D1)
      TimestampEchoReply: 6663975 (0x65AF27)
  - TCPPayload: SourcePort = 52226, DestinationPort = 3389
     RDP: ISOTS
  ISOTS: TPKTCount = 1
- TPKT: version: 3, Length: 19
    version: 3 (0x3)
    Reserved: 0 (0x0)
    PacketLength: 19 (0x13)
- X224: Connection Request
    LengthIndicator: 14 (0xE)
    TypeCredit: Connection Request
    DestinationReference: 0 (0x0)
    SourceReference: 0 (0x0)
    ClassOptions: 0 (0x0)
  - ClientX224ConnectionRequestPdu: 
   - RdpNegReq: TLS 1.0
      Type: 0x1, MUST be set to 0x01
      Flags: 0x0, MUST be set to 0x00
      Length: 0x8, MUST be set to 0x0008
    - RequestedProtocols: TLS 1.0
       SSL:    (...............................1) Support TLS 1.0
       Hybrid: (..............................0.) Not support CredSSP
       Unused: (000000000000000000000000000000..)

--- end Frame Details tree for Frame #67, Connection Request ----

--- begin Frame Details tree for Frame #69, Connection Confirm ---

  Frame: Number = 69, Captured Frame Length = 85, MediaType = ETHERNET
- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-9B-A4-27],SourceAddress:[00-50-56-88-15-CD]
  - DestinationAddress: VMware, Inc. 9BA427 [00-0C-29-9B-A4-27]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
  - SourceAddress: VMWare, Inc. 8815CD [00-50-56-88-15-CD]
     Rsv: (000000..)
     UL:  (......0.) Universally Administered Address
     IG:  (.......0) Individual address (unicast)
    EthernetType: Internet IP (IPv4), 2048(0x800)
- Ipv4: Src = 10.1.2.0, Dest = 10.1.1.126, Next Protocol = TCP, Packet ID = 24937, Total IP Length = 71
  - Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
  - DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT:  (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 71 (0x47)
    Identification: 24937 (0x6169)
  - FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 128 (0x80)
    NextProtocol: TCP, 6(0x6)
    Checksum: 0 (0x0)
    SourceAddress: 10.1.2.0
    DestinationAddress: 10.1.1.126
- Tcp: Flags=...AP..., SrcPort=MS WBT Server(3389), DstPort=52226, PayloadLen=19, Seq=485295779 - 485295798, Ack=2255471226, Win=260 (scale factor 0x8) = 66560
    SrcPort: MS WBT Server(3389)
    DstPort: 52226
    SequenceNumber: 485295779 (0x1CED06A3)
    AcknowledgementNumber: 2255471226 (0x866FC27A)
  - DataOffset: 128 (0x80)
     DataOffset: (1000....) 32 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
  - Flags: ...AP...
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....1...) Push Function
     Reset:  (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 260 (scale factor 0x8) = 66560
    Checksum: 0x17B9, Disregarded
    UrgentPointer: 0 (0x0)
  - TCPOptions: 
   - NoOption: 
      type: No operation. 1(0x1)
   - NoOption: 
      type: No operation. 1(0x1)
   - TimeStamp: 
      type: Timestamp. 8(0x8)
      Length: 10 (0xA)
      TimestampValue: 6663976 (0x65AF28)
      TimestampEchoReply: 66220241 (0x3F270D1)
  - TCPPayload: SourcePort = 3389, DestinationPort = 52226
     RDP: ISOTS
  ISOTS: TPKTCount = 1
- TPKT: version: 3, Length: 19
    version: 3 (0x3)
    Reserved: 0 (0x0)
    PacketLength: 19 (0x13)
- X224: Connection Confirm
    LengthIndicator: 14 (0xE)
    TypeCredit: Connection Confirm
    DestinationReference: 0 (0x0)
    SourceReference: 4660 (0x1234)
    ClassOptions: 0 (0x0)
  - ServerX224ConnectionConfirmPdu: 
   - RdpNegRsp: TLS 1.0
      Type: 0x2, MUST be set to 0x02
      Flags: The server supports Extended Client Data Blocks in the GCC Conference Create Request user data
      Length: 0x8, MUST be set to 0x0008
      SelectedProtocol: TLS 1.0

--- end Frame Details tree for Frame #69, Connection Confirm ---

Paul,

After some internal discussion at my company, I can send you a capture file that has the first 11 packets of my larger capture file.  The shorter capture file includes the problematic encryption handshake and it fails just as my longer capture file does.  I can also send along the corresponding ".pfx" file and my log file of the decryption failure.  Just let me know where to send the files.  Alternatively, I can open up an issue on the Issue Tracker and post the files there.  Please let me know your preference.

Thanks,

-- Steve Ross

Yes, please send them to me.  It will be a lot faster if I can use the debugger to find the issue.

 Thanks,

Paul

From: PaulLong

Yes, please send them to me. It will be a lot faster if I can use the debugger to find the issue.

Thanks,

Paul

Contact me directly via the blog, http://blogs.technet.com/netmon.  That will send email to me and then I can respond and we can continue via email.

Paul

Just to close the loop on this discussion, Paul found that my RDP client was sending a TLS "Client Hello" message that had an extra byte at the end of the frame.  He wrote "We detect this as TLS fragmentation, which causes us to wait for the full segment.  And this in turn screws up the expert."

-- Steve

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

My NetMon version info:

Microsoft Network Monitor 3.4 (Version 3.4.2350.0)

Network Monitor Parsers: 03.04.2774.0001

Dan

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

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