["Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx>]

Hello Steve,

unfortunately because of strange desegmentation handlig of decrypted
data in SSL dissector both cases cause some problems.
If there are 2 or more data records in one frame then:

1) original handlig without your change:
   1st pass through frame (pinfo->fd->flags.visited==0)
    - 1st record is decrypted and subdissector is called
    - next record is decrypted, data are appended to already decrypted
one and subdissector is called for whole merged data
   next passes through frame
    - for each data record subdissector is called for merged data from
all records

2) handlig with your change:
   1st pass through frame (pinfo->fd->flags.visited==0)
    - 1st record is decrypted and subdissector is called
    - next record is decrypted, data are appended to already decrypted
one but no subdissecor is called
   next passes through frame
    - for the 1st data record subdissector is called for merged data
from all records

Problem of original variant 1) is that subdissector is called more times
then it should be and it causes some duplications.
Problem of changed variant 2) is that subdissector is not called for 2nd
and next data records during the 1st pass, i.e. info column does not
contain information from subdissector and coloring based on subdissector
does not work. If subdissector does something important during the 1st
pass then it would fail completely.


I can see two possible solution how to handle it:
1) do not merge decrypted data from different record within one frame
and handle them one by one
2) merge those data but call subdissector only from the last SSL record
for all merged data

I prefer solution 1) as it is nearer to similar solutions in Wireshark.
But it would require more changes in desegmentation of application
protocol across more frames.

What is your opinion?

Best regards,
  Tomas


-----Original Message-----
From: Stephen Fisher [mailto:stephentfisher@xxxxxxxxx] 
Sent: Thursday, January 04, 2007 8:49 PM
To: Kukosa, Tomas
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
20247:/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ssl.c


On Thu, Jan 04, 2007 at 10:21:01AM +0100, Kukosa, Tomas wrote:

> 
> sample capture is attached (trace_logon2.cap).
> The private key is in the key.pem file. Please, do not distribute it
> somewhere else!
> wrs_debug_OK.txt contains log if your change is commented out.
> wrs_debug_ERR.txt contains log with you changes where subdissector is
> not called.
> 
> Keys configuration you can see at the begining of logfile. Only
> 163.242.117.135,4061,tc,D:\Ethereal\ssl_decrypt\key.pem line is
> necessary.
> 
> We use private dissector but I have made changes to call 'data'
> dissector if real protocol is nout found.
> I will commit my changes now to have common code. (revision is 20300)
> 
> I hope we will find solution fulfilling all our needs.

Thanks.  In my testing with HTTP and IMAP over SSL, the data from each 
application data record was combined into one and displayed identical 
data twice in the dissector tree/tabs on bottom.  This led me to make 
the change to only display the information when dissecting the first 
application data's record.

With your TC dissector and my changes commented out, do you not see this

duplication - where it shows the same information two times in the tree 
and tabs?  If you don't, then I will need to back out my changes and 
think about it more.


Steve