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.