Some VoIP TLS packets not decrypted

Question

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.

Answer 1

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?)?