ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] SSL issue not decoding data

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Mon, 19 May 2008 23:24:16 +0200
Sake Blok schrieb:
On Thu, May 01, 2008 at 05:27:05PM -0700, Guy Harris wrote:
On May 1, 2008, at 2:54 PM, Sake Blok wrote:

This line indicates that the SSL session at hand is actually a reused
SSL session with a short handshake. Wireshark needs the full SSL handshake
to be able to calculate all the keys.
Should this somehow be indicated in the UI - possibly even in the dissection itself, so it's indicated in both Wireshark and TShark - so that it's more obvious why you're not getting any decryption done?

Well, one option would be to have expert-messages, but I'm not really
fond of that idea. There is nothing "wrong" with the traffic so we don't want people starting to think their ssl sessions fail, just
because there are expert-messages stating *shark can't decrypt the
traffic.
Expert messages don't necessarily mean something is wrong with the data. Just think about you're looking over the shoulder of someone using Wireshark and telling him what you think as an expert of that protocol.

In this example, I would expect something like: "Full SSL handshake wasn't captured, can't dissect".


I'm doing something similiar in the DCE/RPC dissector, as you simply cannot dissect any messages if you couldn't capture the initial binding handshake (packet-dcerpc.c, line 3409):

expert_add_info_format(pinfo, pi, PI_UNDECODED, PI_NOTE, "No bind info for interface Context ID:%u", ctx_id);

Hmmm, thinking about this line, there's also possible improvement in the message text here, to better tell users what's going on ;-)
I would think an SSL-decryption wiki-page gives more room to really
explain what's going on in different situations. We could add a link
to that wiki-page from the ssl preferences. That excludes tshark
users a bit, but wouldn't they have started with SSL decryption
in wireshark before they started using it in tshark?

Any other ideas? If not, I will try to find some time to work on
a detailed ssl decryption page, as there are quite a bit of questions
asked about "Why doesn't wireshark decrypt my ssl traffic".
Having a more detailed page about SSL decryption would be a good idea anyway ;-)

Regards, ULFL