Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6596] New: Some TLS/Application Data packets not decrypted

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6596

           Summary: Some TLS/Application Data packets not decrypted
           Product: Wireshark
           Version: 1.6.3
          Platform: x86
        OS/Version: Windows 7
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
        ReportedBy: mcclown@xxxxxxxxx


Build Information:
Build Information:
Version 1.6.3 (SVN Rev 39702 from /trunk-1.6)

Copyright 1998-2011 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 (32-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3,
with
Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Nov
 1 2011), with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, 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.10.3, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 21022
--
I've been looking a collection of SSL sites with Wireshark and a debug build of
Firefox that dumps the SSL pre-master secrets so that I can use them to decrypt
the SSL traffic. Wireshark now supports working with these dumps since the
patch in #4349 was applied. As part of this work I've noticed a few bugs or
missing features in wiresharks SSL decryption functionality. I've opened this
issue to track one of them.

I have a few captures where some of the TLSv1/Application Data packets appear
to not be decrypted. I've attached some captures with the corresponding
pre-master secrets. The captures where done on a machine that wash freshly
built and used for the first time for this capture, also I waited for all tcp
connections to close before ending the capture, so all relevant packets shoould
be present.The easiest way to open them is to use the following command line
parameters with wireshark.

wireshark.exe -o ssl.keylog_file:"<path to keyfile>" <path to pcap>

Digging a little deeper I see that according to the ssl debug file in
Wireshark, the packets in question seem to be decrypted, but the GUI doesn't
show this. The  relevant lines in the debug file are below.

Any ideas?

dissect_ssl enter frame #17 (first time)
  conversation = 03FC1B24, ssl_session = 03FC1E8C
  record: offset = 0, reported_length_remaining = 1460
dissect_ssl3_record: content_type 23
decrypt_ssl3_record: app_data len 32, ssl state 0x3F
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
ssl_decrypt_record ciphertext len 32
Ciphertext[32]:
ed 0d 35 ac 49 70 50 24 1f 1a c1 68 be 26 0a 84 
6c 01 5d 77 61 17 c0 a9 ca 00 b8 3a 20 a3 09 02 
Plaintext[32]:
40 67 f0 7a ad 01 05 a8 0a e2 9d f2 6e 68 df 44 
d9 c4 3e 6c 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 
ssl_decrypt_record found padding 11 final len 20
checking mac (len 0, version 301, ct 23 seq 1)
tls_check_mac mac type:SHA1 md 2
Mac[20]:
40 67 f0 7a ad 01 05 a8 0a e2 9d f2 6e 68 df 44 
d9 c4 3e 6c 
ssl_decrypt_record: mac ok
ssl_add_data_info: new data inserted data_len = 0, seq = 0, nxtseq = 0
association_find: TCP port 443 found 03B04218
  record: offset = 37, reported_length_remaining = 1423
  need_desegmentation: offset = 37, reported_length_remaining = 1423

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.