| Bug ID |
8694
|
| Summary |
"Follow SSL Stream..." fails on out-of-order TCP packets
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.0
|
| Hardware |
x86
|
| OS |
Windows XP
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Wireshark
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 10785 [details]
Files according to manifest in submission
Build Information:
Version 1.10.0rc1 (SVN Rev 49062 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Apr 26 2013), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz, with 3071MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
When encountering out-of-order TCP packets, Wireshark typically handles this
just fine in the case of the Follow TCP Stream option, however Follow SSL
Stream stops processing data at this point and displays incorrect decrypted
data to the end user as if it had processed completely.
We're encountering this issue while decrypting inbound email delivered via TLS
to us from large sender MTAs (Google, Yahoo), but I can't share any of those
sessions as the private keys are sensitive. I was able to re-create this issue
by modifying the pcap provided by Joe McEachern in bug 6434 to have identical
out-of-order characteristics to the ones we see in the wild.
If (using the key provided) you Follow SSL Stream on the original pcap file, it
will correctly display the original contents, however if you do the same on the
modified pcap file where the contents (but not the timestamp) of frames 52 and
53 have been swapped you will see Follow SSL Stream breaks at that point and
from there forward.
I've also attached http plaintext pcaps where I did a similar modification,
which demonstrate Follow TCP Stream working as expected.
ATTACHMENT MANIFEST from ssl_bug_files.zip:
connection_SSL-wan.key - RSA key for pcaps
connection_SSL-wan_original.cap - original pcap which Follow SSL Stream
decrypts correctly
connection_SSL-wan_modified.cap - modified pcap (frames 52/53 contents not
timestamp swapped) displays Follow SSL Stream issue
connection_SSL-wan_original.txt - save as raw bytes from original pcap Follow
SSL Stream
connection_SSL-wan_modified.txt - save as raw bytes from modified pcap Follow
SSL Stream
http_original.cap - original plaintext http file
http_modified.cap - modified plaintext http file (frames 10/11 contents
swapped) which Follow TCP Stream displays correctly
You are receiving this mail because:
- You are watching all bug changes.