Wireshark-dev: Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
Ok I found the problem, in the SSL debug log I saw;
association_add TCP port 1364 protocol tls handle 00000000
association_add could not find handle for protocol 'tls', try to find
'data' dissector
Checking the SSL preferences I had an entry for RSA keys list;
127.0.0.1,1364,tls,c:\ssltest.key which specified this port so it was
correctly attempting to dissect this packet as SSL after all.
My follow-up question would be; Is it possible to follow the SSL stream
when the SSL data is embedded in another protocol? This would be a very
useful feature for what I'm working on.
Regards .. Martin
Martin Warnes wrote the following on 12/01/2007 16:27:
Hi,
I'm developing a dissector plugin for the Connect:Direct file transfer
protocol, the protocol itself can contain a SSL payload. Until recently
i didn't have too many problems with my dissector identifying it's own
data, adding some information to the tree and then passing the SSL
payload off to the SSL dissector for subdissection.
I updated the source today and now all the Connect:Direct protocol
packets are being identified as SSL continuation data, this occurs with
or without my dissector plugin loaded.
Example for the packet below:
0000 00 00 03 04 00 00 00 50 ba da b4 6c 00 00 08 00 .......P...l....
0010 45 00 00 51 0e 48 40 00 40 06 aa be c0 a8 00 28 E..Q.H@.@......(
0020 c0 a8 00 28 05 54 86 0b 35 13 e0 4d 35 3a 86 3d ...(.T..5..M5:.=
0030 80 18 20 00 81 e4 00 00 01 01 08 0a 09 53 d3 f3 .. ..........S..
0040 09 53 d3 f3 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2........
0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 ....8...........
0060 00
The Connect:Direct protocol contains a header that starts with "TCP2"
the length of the header is offset +6 (x10), there are 4 bytes of flag
data and then the payload data starts.
54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2........
0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 ....8...........
0060 00 .
In this case the payload is SSL data starting x'16 x'03 x'01
Has something changed in the SSL dissector that may caue this behaviour?
I looked at the SVN history and can't see anything obvious, but a quick
look through the SSL dissector code and I saw some routines called
"ssl_looks_like_". This seems to suggest that the SSL code does a
heuristic attempt to determine whether the packet contains SSL data,
which this does although it is not the only protocol in the packet.
Is there a way to prevent this?
I can work around the problem by using "decode as..", but that's not a
desirable solution.
Regards .. Martin
----------------------------------------------------------
Scanned by ClamAV antivirus system - http://www.clamav.net
Virus signatures last updated: Fri Jan 12 15:33:21 2007
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
��������������������������������������������jy�u�����U����2�צ�m���� �rV�j��z�b��,� ڶ�V���]jם�Z�%���^����m4
----------------------------------------------------------
Scanned by ClamAV antivirus system - http://www.clamav.net
Virus signatures last updated: Fri Jan 12 15:33:21 2007
