This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Unable dissect TLS handshake messages

0

Hi,

We are using Latest Version of wireshark 2.0.3 with GnuTLS 3.2.15, with Gcrypt 1.6.2 on our windows Machine. Also we have wireshark 1.0.15 on CentOS 4.5. We have issue on Both wireshark version on Both OS.

In our case we trying to dissert TLS handshake messages, where we have Netconf messages as payload for TLS messages. i.e we are trying to establish Netconf session over TLS. Our protocol encapsulation will be like TCP--TLS--Netconf

We are trying to see the TLS handshake messages which is used for the Netconf Over TLS session.

But we are not able dessect TLS Handshake messages in this case.

Is there any Limitation from wireshark for this case Netconf over TLS & TCP i.e TCP--TLS-- Netconf.

At the same time, We are able to capture and dissect TLS handshake messages, when we browse https sites.

Please Help

asked 26 May '16, 00:55

dhanish's gravatar image

dhanish
6●3●3●5
accept rate: 0%

Can you share a capture in a publicly accessible spot, e.g. CloudShark?

(26 May '16, 02:36) grahamb ♦

Thanks for the response. Actuall as per another query from wireshark forum i have upgraded my CentOS 5.5 version with wireshark version 1.6.16.

Now am able to capture the TLS traffic and TLS dissector working working on linux CentOS machine. (Note:packet captured on same machine with loopback interface lo).

But the same capture(which is captured in linux on lo interface) when i open from my windows 7 desktop machine which has got the latest wireshark version 2.0-3 - No success. Its display only as TCP packets.

Is it because of windows machine doesnt have loopback lo ? But as said earlier am able to dissect https traffic from my browser from my window machine.

It have uploaded 2 capture files on to cloudshark with tag "callhome" 1.packet - URL - https://www.cloudshark.org/captures/c793bfd6c8d1 2.callhomeTLSwireshark1.6.16 - URL - https://www.cloudshark.org/captures/baa5c0384046

(26 May '16, 06:02) dhanish

We need the "sharing" links to the Cloudshark captures. In the Cloudshark UI, next to each file there is an (i) button, click that then on the resulting dialog click the sharing tab. Edit your question and add the links to the captures there.

(26 May '16, 06:12) grahamb ♦

Hi,

This query is inline with query "Unable to decrypt TLS data from a TLS captured file"

After upgrading the linux CentOS 4.5 with wireshark , as said TLS dissector works fine. Hence i tried to decrypt the TLS data using wireshark GUI- EDIT-Preference-RSA key - ssl_init IPv4 addr '127.0.0.1' (127.0.0.1) port '39515' filename '/home/amanimar/openssl/device.key

In the ssl debug file i find more info than before , but still TLS data is not decrypted,

Debug log uploaded on cloudshark with tag 'callhomessldebuglog' file name "callhomeTlsNew1". - URL - https://www.cloudshark.org/captures/45435a2b6f7b

As i mentioned earlier our packet encapsulation is like this, TCP-TLS-Netconf session details.

Here TLS payload is Netconf protocol, not http - Is that the reason why we are not able decrypt the TLS data ?

RSA key is of PEM format.

Thanks Very Much for the Response !!

(26 May '16, 06:33) dhanish

2 Answers:

0

Are you trying to decrypt the TLS or just dissect it?

Since Wireshark doesn't have a NETCONF dissector if you just want to dissect the TLS messages you can just tell the HTTP dissector that one of its TLS ports is 4444. That should show you the Server Hello, etc. (Maybe there's a less hacky way to get this done.)

In terms of decryption (where I presume you're putting the protocol in the TLS key configuration as data) the log file says:

   dissect_ssl3_hnd_srv_hello can't find cipher suite 0x9D
   record: offset = 63, reported_length_remaining = 934

That means that the Wireshark version that generated that log file does not understand the cipher (TLS_RSA_WITH_AES_256_GCM_SHA384) used in the session. Wireshark 2.0.3 knows that cipher so I'm guessing this was run on RHEL.

To get the decryption working on RHEL you'll need to change the cipher being sent by the NETCONF server (or upgrade Wireshark's version--which you may not be able to do).

Decryption should work on Windows--we'd need to see the log file from that to know what's wrong there.

answered 26 May '16, 14:54

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k●5●72
accept rate: 27%

Thanks Jeff !

Actually traffic is captured at Linux machine Centos 4.5.

On Linux : After upgrading to 1.6.16 able to dessect TLS handshake message. But unable to decrypt - Understand thats because of Unsupported Cipher used between client and server . Will check with dev to make use of another cipher for client server Transcations.

On my Windows 7 am trying to open the captured file from Linux,

Here on Windows:

Am upgraded to latest version 2.0.3. But here TLS dissect itself getting failed . Hence i hope decryption wont happen. At the same time with 2.0.3 am able dissect TLS traffic from my browser, like any https sites.

What might be the reason ? I doubt the interface 'lo' on which handshake was captured. But windows doesnt have 'lo' does it make any impact ?

Thanks Again, Dhanish.

(26 May '16, 22:47) dhanish

0

The server in both captures is on port 4444, so use "Decode as ..." to set tcp\4444 to be SSL. The captures then dissect TLS 1.2 quite happily for me using 2.0.2 on Windows.

To decrypt the data you'll also need to use port 4444 in the RSA Keys list preference setting.

After you've set that, post the SSL debug log for the capture packet.pcap back here.

answered 27 May '16, 02:35

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206
accept rate: 22%

I tried to decrypt with port 4444 but still not working.

but i feel in our case 39515 is TLS server port. Below is our scenario,

CALLHome/TLS Client(4444) CALLHome/TLS server(39515) TCP is intiated <------------------------------------------syn ------------------------------------------------------>syn + ACK <--------------------------------------------------------- Ack On Established TCP connection client will initiate TLS connction with port 39515 ---------------------------------------------------------->client Hello

Dump i am unable to upload to cloudshark - getthing this error "Couldn't read capinfo from this file. Please make sure it is a file Wireshark can read." Not sure Why ?

Thanks Again, Dhanish.

(27 May '16, 05:33) dhanish

Nope, in that capture port 4444 is definitely the server, look at the directions of the packets only carrying a SYN, they are from ephemeral ports to 4444.

Just try it and you'll see TLS dissection. Correct your RSA key setting and you should see decryption as well.

Note also the info on the SSL Wiki page about PEM files and the private key.

(27 May '16, 05:52) grahamb ♦

Dump i am unable to upload to cloudshark - getthing this error "Couldn't read capinfo from this file. Please make sure it is a file Wireshark can read." Not sure Why ?

Because Cloudshark accepts only files which contain packet captures, i.e. files which Wireshark itself can open. The ssl debug file you are trying to upload there is a plain text file so Cloudshark rejects it. So please publish it at some file sharing service (Google drive, Dropbox, ...), login-free, and provide a link to it here.

(27 May '16, 06:01) sindy

re the debug log, or add it to your question by editing the question and pasting the debug log contents.

(27 May '16, 06:05) grahamb ♦

Hi all,

I am continuing with the query which Dhanish have raised. Working for the same team. We are having a packet captured with protocol encapsulation TCP--TLS--Netconf. we are trying to decrypt the packet, but not able to decrypt it. Using the wireshark Version "Version 2.0.3 (v2.0.3-0-geed34f0 from master-2.0)" For decrypting, what we did is: a) Under Edit--> preference -->Selected Protocol 'SSL' --> RSA Key List --> EDIT --> IP Address - 127.0.0.1 Port - 4444 Protocol - http Key File - Path for Server.key. But not able to decrypt the packet.

I am sharing the packet capture --> here.

And also sharing the Key which we are using for Encryption, Sever.key --> here.

Please help me with Decryption.

Thanks, Nancy.

(07 Jun '16, 05:49) Nancy

For whoever understands it better than me but may not look for obvious things, the roles of client and server are swapped between TCP and TLS. The TCP session is initiated from client port 39975 to server port 4444, but the Client Hello packet is sent from server port 4444 to client port 39975 and Server Hello comes from the TCP client. But even defining 39975 as SSL port and relating the RSA key to it doesn't help Wireshark decipher the Application Data.

(07 Jun '16, 06:33) sindy

Odd behaviour indeed, but looking at the SSL debug log I don't think the key is the correct one for the server certificate:

KeyID[20]:
| 3b cd c0 07 7b a3 7d a1 f6 7b 24 b6 aa 38 14 61 |;...{.}..{$..8.a|
| 68 94 e4 06                                     |h...            |
ssl_load_key: swapping p and q parameters and recomputing u
ssl_init private key file C:/Users/graham.bloice/Downloads/server.key successfully loaded.
ssl_init port '39975' filename 'C:/Users/xxx/Downloads/server.key' password(only for p12 file) ''
association_add ssl.port port 39975 handle 04ABAAD8

...

dissect_ssl enter frame #6 (first time)
packet_from_server: is from server - TRUE
  conversation = 068ADE78, ssl_session = 068AE4D8
  record: offset = 0, reported_length_remaining = 997
ssl_try_set_version found version 0x0303 -> state 0x11
dissect_ssl3_record: content_type 22 Handshake
Calculating hash with offset 5 58
decrypt_ssl3_record: app_data len 58, ssl state 0x11
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 2 offset 5 length 54 bytes, remaining 63 
ssl_try_set_version found version 0x0303 -> state 0x11
ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x13
ssl_dissect_hnd_srv_hello found CIPHER 0x009D TLS_RSA_WITH_AES_256_GCM_SHA384 -> state 0x17
  record: offset = 63, reported_length_remaining = 934
dissect_ssl3_record: content_type 22 Handshake
Calculating hash with offset 68 878
decrypt_ssl3_record: app_data len 878, ssl state 0x17
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 11 offset 68 length 874 bytes, remaining 946 
lookup(KeyID)[20]:
| 4b 0b 80 88 a1 54 bc ee 75 94 cd 1e f1 4e 95 84 |K....T..u....N..|
| bd a0 4b 9c                                     |..K.            |
ssl_find_private_key_by_pubkey: lookup result: 00000000
(07 Jun '16, 06:47) grahamb ♦
showing 5 of 7 show 2 more comments