ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 9154] New: HTTP response is not shown when Content-Length

Date: Mon, 16 Sep 2013 11:22:16 +0000
Bug ID 9154
Summary HTTP response is not shown when Content-Length is missing in a SSL stream
Classification Unclassified
Product Wireshark
Version SVN
Hardware All
OS All
Status UNCONFIRMED
Severity Normal
Priority Low
Component Dissection engine (libwireshark)
Assignee [email protected]
Reporter [email protected]

Created attachment 11588 [details]
pcapng file for HTTP response without Content-Length

Build Information:
1.10.2-trunk (SVN revision 52051)

Compiled (64-bit) with GTK+ 2.24.20, with Cairo 1.12.16, with Pango 1.34.1,
with
GLib 2.36.4, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux),
with libnl 3, without SMI, without c-ares, without ADNS, with Lua 5.2, without
Python, with GnuTLS 3.2.4, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP,
with PortAudio V19-devel (built Feb 24 2012 12:00:16), without AirPcap.

Running on Linux 3.11.0-1-custom, with locale en_US.UTF-8, with libpcap version
1.4.0, with libz 1.2.8, GnuTLS 3.2.4, Gcrypt 1.5.3.
Intel(R) Core(TM) i5 CPU       M 460  @ 2.53GHz

Built using gcc 4.8.1 20130725 (prerelease).
--
A HTTP response within a SSL stream without Content-Length does not get
dissected. Instead, the decrypted Application Data records are labeled with
"[SSL segment of a reassembled PDU]". This is understandable since Wireshark
cannot know when the HTTP stream ends.

When a TCP FIN is found, I would expect the reassembled HTTP response to be
shown (even if there is no TLS traffic anymore).

The issue occurs in this flow:
10. C->S [TCP] [TLS] [HTTP GET / HTTP/1.0]
11. S->C [TCP] [TLS] [HTTP response w/o Content-Length] "SSL segment .. PDU"
12. S->C [TCP FIN/ACK] <-- Here I expect the assembled HTTP response
13. C->S [TCP] [TLS Alert: Close Notify]
14. S->C [TCP RST]

This problem is probably not limited to HTTP, but any protocol where the end is
unknown.


See the attached capture. Save "CLIENT_RANDOM 52..44 7F..DF" as "premaster.txt"
(see below) and run the following:

wireshark -o ssl.keylog_file:$PWD/premaster.txt -o http.ssl.port:4430
dump.pcapng

5236da07b7272304418a421f129fc21a5786e50226348586f649a4546e519144

7F7ED1FFB65D2264182BC823873B82D0E167A1911B1B67D97C28642816D9D05503C1A34F6EDCAE2D1059DAA8BF0ADADF


You are receiving this mail because:
  • You are watching all bug changes.