| Bug ID |
12793
|
| Summary |
Expert Info ssl.resumed incorrect after TLS renegotiate
|
| Product |
Wireshark
|
| Version |
2.0.5
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Qt UI
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14862 [details]
pcap containing a TLS renegotiate (two TLS handshakes in one TCP stream and a
TLS "Hello Request")
Build Information:
Version 2.0.5 (v2.0.5-0-ga3be9c6 from master-2.0)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.38.0, with SMI 0.4.8,
with c-ares 1.11.0, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with
MIT Kerberos, with GeoIP,
with QtMultimedia, with AirPcap.
Running on 32-bit Windows 7 Service Pack 1, build 7601, with locale
Dutch_Netherlands.1252, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version
1.0 branch 1_0_rel0b
(20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (with SSE4.2), with 3317MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 40629
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Attached pcap contains a TLS renegotiate (two TLS handshakes and a TLS "Hello
Request" in one TCP stream).
Using the display filter "ssl.resumed" in either Wireshark or tshark will
filter 2 frames as a resumed session: frames 6 and 57.
But looking at the data the second handshake is NOT a resumed session.
The SSL debug log shows the following:
dissect_ssl enter frame #57 (first time)
packet_from_server: is from server - TRUE
conversation = 104E0C58, ssl_session = 104E1288
record: offset = 0, reported_length_remaining = 59
dissect_ssl3_record: content_type 20 Change Cipher Spec
ssl_dissect_change_cipher_spec Not using Session resumption
So there is a mismatch between the expert Info / display filter and the ssl
dissector.
Client = 192.168.12.12
Server = 192.168.12.2
Note: this bug is also reproduced with:
Version 2.1.0-1950-g65d4222 (v2.1.0rc0-1950-g65d4222 from master) Running on
64-bit Windows 10,
(this version does not display the HTTP response.)
You are receiving this mail because:
- You are watching all bug changes.