SSL Dissector working

Question

Hi,

I wanted to know if every time i select a new SSL packet is the packet decrypted and dissected again. To be clearer If I give Wireshark the necessary info such as the session key and the client random the ssl stream is decrypted. Does this happen every time the packet is selected or it just happens once and we keep the whole decrypted frame?

My intuition says it must be the Decrypted every time as keeping a decrypted record for every packet sounds impractical. Can someone please comment on this? Thanks

-Koundi

Accepted Answer

1

Once the TLS record is decrypted, it will be cached for future use.

Basically it works like this:

The first time a packet is seen, decryption is tried. If the packet is visited again later (because you select the packet for example), it will be skipped. From the dissect_ssl function:
```
/* try decryption only the first time we see this packet
 * (to keep cipher synchronized) */
if (pinfo->fd->flags.visited)
     ssl_session = NULL;
```

Function dissect_ssl3_record will try to decrypt the record if the SslDecryptSession pointer is still valid (here, ssl is the same as ssl_session above).

    if (ssl){
        decrypt_ssl3_record(tvb, pinfo, offset,
            record_length, content_type, ssl, TRUE);
    }
    ...
    dissect_ssl_payload(tvb, pinfo, offset, tree, session, app_handle);

Function decrypt_ssl3_record will try to decrypt the data and then calls ssl_add_data_info to cache the result (on success). Note that this is only invoked the first time.
Function dissect_ssl_payload will try to load the decrypted data via ssl_get_data_info. This may be invoked multiple times for the same packet.

permanent link

answered 17 Oct '16, 03:22

Lekensteyn
2.2k●3●7●24
accept rate: 30%

so you what you are basically saying is it does store the decrypted record for every packet ?

(17 Oct '16, 03:26) koundi

Yes it does store the decrypted record for every packet. Note that only the data (bytes) are stored, not the tree itself.

(17 Oct '16, 03:31) Lekensteyn

yup! thanks. Also can you please tell me why not just store the tvb instead of the bytes. When the packet is decrypted first time when the visited flag is not set then we create a tvb and add it as a data source and pass it onto the next dissectors.

So when I come back to the same point and get the existing decrypted record and create another tvb is not a redundancy? or is tvb not file scoped ??

Thanks a lot for answering these questions! I knew you would be the one answering this question :)

(17 Oct '16, 05:53) koundi

Ok, actually when I said "bytes", I meant the tvb which was created from the decrypted data. This seems a good trade-off between memory use and CPU usage :)

(17 Oct '16, 06:01) Lekensteyn

I am sorry but when I look into the code it looks like the ssl_add_data_info is actually copying the character array(guchar*) using wmem_alloc and doing a memcpy with a file scope.

But by doing this isnt the first tvb left dangling?(yes later when tvb_free is called it is freed) but we are creating two tvbs with the same data are we not?? Can you please tell me when the tvb goes out of "scope"? Thanks again!

(17 Oct '16, 06:18) koundi

Ok sorry for the misinformation, I just looked again and indeed the decrypted data is first stored in the SslDataInfo structure. A new Tvb is created every time in dissect_ssl_payload based on this data, but it seems that the real data is not copied, only a pointer seems stored (see tvb_new_child_real_data -> tvb_new_real_data, the data pointer is stored in the real_data member).

Based on the comments in epan/tvbuff.h, a Tvb is freed when returning to the top-level dissector. All chained (child) Tvbs are also released at the same time (but note that the "real data" is not freed because the free_cb is not set in tvb_new_real_data).

As for the SSL memory, note it is using wmem-allocated memory from the wmem_file_scope pool which means that the memory is released when the packet file closed.

(17 Oct '16, 06:40) Lekensteyn

yes thanks a lot!

(17 Oct '16, 06:52) koundi

showing 5 of 7 show 2 more comments

SSL Dissector working

Follow this question

You have a trillion packets.

You need to see four of them.

Don't have Wireshark?

Related questions