https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4535
Summary: The SSL dissector can not correctly resemple SSL
records when the record header is spit between packets
Product: Wireshark
Version: 1.2.6
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: High
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: milkovm@xxxxxxxxxxx
Created an attachment (id=4332)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4332)
Capture that shows the problem
Build Information:
wireshark 1.2.6 (SVN Rev 31702)
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.18.5, with GLib 2.22.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8,
with c-ares 1.7.0, with Lua 5.1, with GnuTLS 2.8.5, with Gcrypt 1.4.5, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jan 27 2010), with
AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.1
(packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
--
If the header of a SSL record is split between 2 packets, the SSL dissector
will not be able to resemble the record correctly. In order to see the problem
please load the attached capture (it represent one single TCP session carrying
SSL) and go to packet 353. Go to the SSL section - there is one TLS record in
it. If you highlight it and go to the end of the packet you'll see that there
are 2 bytes in this packet after the TLS record ends. These bytes are 0x1703.
This is the beginning of the next TLS record. The next packet from the server
is 355. If you highlight the TCP segment data, you'll see that the TLS header
from the previous packet continues here with 0x010810.... The last two bytes
from packet 353 and the first 3 bytes from packet 355 represent the next TLS
record header - 0x1703010810. These bytes mean that we have a TLS record with
lenght 0x0810 or 2064 in decimal. If you now calculate 2064 bytes from the end
of the header, you'll end up in the payload of packet 356 and you'll see that
immediatly after these 2064 bytes there is the beginning of the next TLS
record. But if you look at how the Wireshark describes packet 356, you'll
understnad that the SSL dissector obvioulsly misscalculated something because
packet 356 and everything after this packet is shown by Wireshark as "Ingnored
Unknown Record". Because of this of course the SSL dissector can not decrypt
anything from now on if presented with a key.
There are large SSL records (more than 1 packet) in captures that I've seen
that don't cause this problem in Wireshark. The difference between them and
this case here as far as I could figure it out is the fact that the SSL record
header is split between packets when the problem appears.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
