Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 20247:/trunk/epan/dissectors/ /trunk
From: "Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx>
Date: Fri, 5 Jan 2007 08:48:13 +0100
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
- Prev by Date: Re: [Wireshark-dev] Microsoft Visual C Version 6 support isa bitoutdated ...
- Next by Date: Re: [Wireshark-dev] Are user decodes persisted?
- Previous by thread: Re: [Wireshark-dev] Ubuntu&Solaris Buildbot error: gcc: @SHAREDLIB_LDFLAGS@: No such file or directory
- Next by thread: Re: [Wireshark-dev] [Wireshark-commits] rev 20247:/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ssl.c
- Index(es):