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

I'm writing a new dissector for a protocol that can include SSL traffic. It is somewhat similar to LDAP in that it can start a session unencrypted and switch to SSL on the same port when a certain message is received, so I've based my code on packet-ldap. I've also referred to packet-pop, packet-http, and packet-xmpp, which all have various forms of this code.

At the appropriate points, my code is successfully getting to:

call_dissector(ssl_handle, tvb, pinfo, tree);

But in the output of tshark, I don't see any decrypted data:

tshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list: 172.16.244.160,52230,amp,cacert.key" -r ../tests/AMP-connect-SSL-trimmed.pcap -x

All this prints is the encrypted data.

If I switch the protocol to ldap, http or xmpp, then I get SSL decryption:

tshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list: 172.16.244.160,52230,ldap,cacert.key" -r ../tests/AMP-connect-SSL-trimmed.pcap -x

Frame (140 bytes):
0000  00 0c 29 22 80 34 00 50 56 c0 00 08 08 00 45 00   ..)".4.PV.....E.
0010  00 7e 31 1a 40 00 40 06 c8 9c ac 10 f4 01 ac 10   [email protected]@.........
0020  f4 a0 f0 e6 cc 06 5d df 0c 2f b2 cc ff fa 80 18   ......]../......
0030  20 00 39 1d 00 00 01 01 08 0a 34 15 f0 11 09 a1    .9.......4.....
0040  28 8f 17 03 00 00 20 ad d1 99 13 3a 22 ec 45 b9   (..... ....:".E.
0050  b1 ec 0e 1f 52 e7 84 d8 b9 27 9a 72 60 66 17 f2   ....R....'.r`f..
0060  95 2a 82 8e 5a 3b 39 17 03 00 00 20 3c fc 1e d2   .*..Z;9.... <...
0070  b2 de 70 01 9b a7 00 b1 e9 3f 06 87 1d 5a 51 67   ..p......?...ZQg
0080  51 9d 2e 59 0b b1 35 a0 a2 de 37 a6               Q..Y..5...7.
Decrypted SSL data (9 bytes):
0000  00 00 00 01 01 00 00 00 02                        .........

My code is almost identical to the ldap code. I've tried basing my code on the http, pop, xmpp code (which are all a little different), to no effect. I also tried going back to the dissector_t interface rather than new_dissector_t, but that didn't change anything.

    if (amp_info &&
            amp_info->start_tls_frame &&
            ( pinfo->fd->num >= amp_info->start_tls_frame))
    {
        guint32 old_start_tls_frame;

        dissector_delete_uint("tcp.port", AMP_PORT, amp_handle);
        ssl_dissector_add(AMP_PORT, "amp", TRUE);

        old_start_tls_frame = amp_info->start_tls_frame;
        amp_info->start_tls_frame = 0; /* make sure we don't call SSL again */
        pinfo->can_desegment++; /* ignore this layer so SSL can use the TCP resegment */

        int dissected_length = call_dissector(ssl_handle, tvb, pinfo, tree);

        amp_info->start_tls_frame = old_start_tls_frame;
        ssl_dissector_delete(AMP_PORT, "amp", TRUE);

        /* restore AMP as the dissector for this port */
        dissector_add_uint("tcp.port", AMP_PORT, amp_handle);

        /* we are done */
        return dissected_length;
    }

I'm not certain where next to troubleshoot. Is there something else dissectors need to do in order to use SSL? I'm not getting warnings or errors.

asked 07 Jan '14, 09:38

Rob%20Napier's gravatar image

Rob Napier
26337
accept rate: 100%


The developers mailing list is probably a better place to ask questions like this one ;-)

Regards
Kurt

permanent link

answered 07 Jan '14, 12:06

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks. I wasn't certain what each forum's "level" was.

(07 Jan '14, 12:07) Rob Napier

Some developers are here as well, but by far not all...

(07 Jan '14, 12:09) Kurt Knochner ♦

Since commit 93ed72642b3bc0771c6099c4861a39c080040b0e (v1.99.3rc0-71-g93ed726), you can use the new ssl_starttls_ack function to mark a conversation for continuation as SSL/TLS. This function takes care of reassembly and other details that are needed before handling the decrypted traffic to the dissector.

The code from your question has the issue that it makes the protocol dissector (XMPP) fully aware of the SSL layer above the protocol. As dissectors should not need to know the details between the transport layer and SSL, the new ssl_starttls_ack function abstracts some details for you.

For examples on application of this function, see commit e190253478cea8ab10903e83daafeb3574ad0f04. You basically have to call ssl_starttls_ack() whenever you found the last plaintext packet before SSL and then the SSL dissector will ensure that your dissector is called for future decrypted packets.

Here is the prototype from packet-ssl-utils.h:

/** Marks this packet as the last one before switching to SSL that is supposed
 * to encapsulate this protocol.
 * @param ssl_handle The dissector handle for SSL or DTLS.
 * @param pinfo Packet Info.
 * @param app_handle Dissector handle for the protocol inside the decrypted
 * Application Data record.
 * @return 0 for the first STARTTLS acknowledgement (success) or if ssl_handle
 * is NULL. >0 if STARTTLS was started before.
 */
extern guint32
ssl_starttls_ack(dissector_handle_t ssl_handle, packet_info *pinfo,
                 dissector_handle_t app_handle);
permanent link

answered 10 Feb '15, 07:21

Lekensteyn's gravatar image

Lekensteyn
2.2k3724
accept rate: 30%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×637
×319

question asked: 07 Jan '14, 09:38

question was seen: 3,809 times

last updated: 10 Feb '15, 07:21

p​o​w​e​r​e​d by O​S​Q​A