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

Some VoIP TLS packets not decrypted

0

Using Wireshark 2.2.7 under Windows 7 x64.

I have an idea what is going on here but maybe someone can confirm.

I have a TLS-encrypted trace of a conversation between a VoIP phone and a PBX. I've supplied the private key from the PBX to Wireshark. I started the trace on the server before reconnecting the phone (turning on the relevant account in the phone), and I can see what I think is a successful key exchange (Client Hello, Server Hello, Client Key Exchange, New Session Ticket) between packets 25 and 31.

Many packets are decrypted just fine, like this REGISTER:

dissect_ssl enter frame #37 (first time)
packet_from_server: is from server - FALSE
  conversation = 00000249A3822E80, ssl_session = 00000249A3823850
  record: offset = 0, reported_length_remaining = 933
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 928, ssl state 0x63F
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
ssl_decrypt_record ciphertext len 928
Ciphertext[928]:
| 5a 3c e1 35 d5 95 56 87 29 8b 2a f2 d7 fe 47 bd |Z<.5..V.).*...G.|
[snip]
ssl_decrypt_record: allocating 960 bytes for decrypt data (old len 688)
Plaintext[928]:
| 52 45 47 49 53 54 45 52 20 73 69 70 3a 70 62 75 |REGISTER sip:pbu|
[snip]
ssl_decrypt_record found padding 6 final len 921
checking mac (len 901, version 301, ct 23 seq 2)
tls_check_mac mac type:SHA1 md 2
Mac[20]:
| 14 ff 77 e6 0a 23 5e cd 4a 37 dd 9a ff 83 ef 66 |..w..#^.J7.....f|
| 93 aa 5a 28                                     |..Z(            |
ssl_decrypt_record: mac ok
ssl_add_data_info: new data inserted data_len = 901, seq = 621, nxtseq = 1522
dissect_ssl3_record decrypted len 901
decrypted app data fragment[901]:
| 52 45 47 49 53 54 45 52 20 73 69 70 3a 70 62 75 |REGISTER sip:pbu|
[snip]
process_ssl_payload: found handle 00000249A0F9A3D0 (sip)
packet_from_server: is from server - FALSE

However some tell me no decoder available:

dissect_ssl enter frame #54 (first time)
packet_from_server: is from server - TRUE
  conversation = 00000249A3820220, ssl_session = 00000249A3820790
  record: offset = 0, reported_length_remaining = 74
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 32, ssl state 0x10
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
  record: offset = 37, reported_length_remaining = 37
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 32, ssl state 0x10
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available

I see now that the ssl_session identifiers differ. Have I got multiple TLS conversations going on here? My hunch is that somehow there was a cached key from the previous connection. Why would it use an old key and negotiate a new one? I guess I will try a full phone reboot to force it to lose old keys.

asked 11 Jul '17, 16:06

mcbsys's gravatar image

mcbsys
6113
accept rate: 0%


One Answer:

0

TLS decryption requires the presence of the full handshake from both the client and server side. In your log, we can find the following line:

decrypt_ssl3_record: app_data len 32, ssl state 0x10

The internal state field is a bitmap, 0x10 means that the SSL_VERSION flag is set and nothing else. That is suspicious. At least the following masks are expected to be set:

  • 0x01 SSL_CLIENT_RANDOM - indicating that the Client Hello message was seen.
  • 0x02 SSL_SERVER_RANDOM - indicating that the Server Hello message was seen.

Lack of either suggests that your capture has started in the middle and is missing the handshake messages. Is it possible that a TCP/TLS connection was already active (for a different SIP account?)?

answered 13 Jul '17, 11:34

Lekensteyn's gravatar image

Lekensteyn
2.2k3724
accept rate: 30%

Thanks. The capture was done on the server with a host filter on the client's IP. AFAIK, there was only one account active through that IP at the time. You can see ssl_state 0x63F in the packet #37. The only thing I could guess was that a previous session (before I deactivated and re-activated the account on the phone) was cached? I re-ran the test, rebooting the phone, and did not seem to have this overlapping certs issue. I did eventually get a bad mac error, which is what we are actually trying to debug; waiting to hear from the phone vendor after submitting the new trace.

(13 Jul '17, 18:20) mcbsys

Frame 54 has a different conversation ID than 37 and must be a different connection. You can check this by adding a column for the tcp.stream field. What do you mean by "caching"? If it means "it did not close the previous connection", then that could explain it. If it means "it uses session resumption", then no, it would still result in an abbreviated handshake.

(14 Jul '17, 07:30) Lekensteyn