Bug ID |
10984
|
Summary |
SSL Decrypted Packet Not Decoded As HTTP
|
Product |
Wireshark
|
Version |
1.12.3
|
Hardware |
x86
|
OS |
Mac OS X 10.9
|
Status |
UNCONFIRMED
|
Severity |
Major
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 13457 [details]
Example with SSL traffic
Build Information:
# tshark -v
TShark 1.12.3 (v1.12.3-0-gbb3e9a0 from master-1.12)
Copyright 1998-2015 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 (64-bit) with GLib 2.36.0, with libpcap, with libz 1.2.3, without
POSIX
capabilities, with SMI 0.4.8, without c-ares, without ADNS, with Lua 5.2,
without Python, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with
GeoIP.
Running on Mac OS X 10.9.5, build 13F34 (Darwin 13.4.0), with locale
en_US.UTF-8, with libpcap version 1.3.0 - Apple version 41, with libz 1.2.5.
Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
12336.9.00).
--
Tshark is not decoding decrypted SSL traffic unless I set what I believe should
be unrelated preferences. For example running the following command:
# tshark -r https_example_com.pcapng -T text -V -Y frame.number==15 -o
"ssl.keylog_file:./https_example_com.masterkey"
Gives me the following (after the tcp header):
Secure Sockets Layer
TLSv1.2 Record Layer: Application Data Protocol: spdy
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 411
Encrypted Application Data:
00000000000000017b33bdb27c5796802dc26dc0a0df7a14...
SSL segment data (387 bytes)
If I set an HTTP option to decompress the body I see:
# tshark -r https_example_com.pcapng -T text -V -Y frame.number==15 -o
"ssl.keylog_file:./https_example_com.masterkey" -o "http.decompress_body:FALSE"
Secure Sockets Layer
TLSv1.2 Record Layer: Application Data Protocol: http
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 411
Encrypted Application Data:
00000000000000017b33bdb27c5796802dc26dc0a0df7a14...
Hypertext Transfer Protocol
GET /favicon.ico HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET /favicon.ico HTTP/1.1\r\n]
[GET /favicon.ico HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /favicon.ico
Request Version: HTTP/1.1
Host: www.example.com\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0)
Gecko/20100101 Firefox/35.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-US,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Connection: keep-alive\r\n
If-Modified-Since: Fri, 09 Aug 2013 23:54:35 GMT\r\n
If-None-Match: "359670651"\r\n
\r\n
[Full request URI: https://www.example.com/favicon.ico]
[HTTP request 1/1]
However this data is not compressed and I do not believe that this option
should have an effect. Setting the value of http.decomnpress_body to TRUE
results in this traffic not being decoded as HTTP (TRUE is the default value).
Tshark is able to decrypt this traffic without the http option set:
# tshark -r https_example_com.pcapng -x -Y frame.number==15 -o
"ssl.keylog_file:./https_example_com.masterkey"
Frame (502 bytes):
0000 00 50 f1 80 00 00 68 5b 35 a4 dd a8 86 dd 60 05 .P....h[5.....`.
0010 08 4d 01 c0 06 40 26 01 00 06 74 82 b6 00 59 1f .M...@&...t...Y.
0020 6d 61 cc 3f f9 62 26 06 28 00 02 20 00 01 02 48 ma.?.b&.(.. ...H
0030 18 93 25 c8 19 46 e6 93 01 bb c8 71 c5 e8 99 f6 ..%..F.....q....
0040 b4 1c 80 18 20 00 88 84 00 00 01 01 08 0a fa 53 .... ..........S
0050 48 ea 0d c4 1a 33 17 03 03 01 9b 00 00 00 00 00 H....3..........
0060 00 00 01 7b 33 bd b2 7c 57 96 80 2d c2 6d c0 a0 ...{3..|W..-.m..
0070 df 7a 14 49 1a e1 eb 6f 47 bc fb 6c f6 f0 c9 72 .z.I...oG..l...r
0080 4d da e3 31 84 fd 06 15 f6 ea 67 20 35 36 71 78 M..1......g 56qx
0090 e2 a4 72 d8 bd b3 0d 65 6f 85 6b 23 52 7a 4a dd ..r....eo.k#RzJ.
00a0 75 4e 0a 81 82 82 e3 6e 49 af 7d 9b 61 a9 25 60 uN.....nI.}.a.%`
00b0 34 66 89 ba 96 fd 66 e8 dc 1e cd a9 d9 9f e6 eb 4f....f.........
00c0 a3 d0 d4 04 cd 78 c5 2d 9c c7 13 11 3b b1 de d0 .....x.-....;...
00d0 21 35 b0 0f 05 1c 23 80 4b 97 4b 8d d7 f5 ec 79 !5....#.K.K....y
00e0 e3 ad ba fa 17 f9 85 74 18 24 42 02 65 88 e0 30 .......t.$B.e..0
00f0 09 41 f6 73 7f 35 b8 a3 67 6a 0c cc ce f8 d7 61 .A.s.5..gj.....a
0100 de 6c c6 ba f0 87 04 41 56 49 52 9a f6 16 1b 6f .l.....AVIR....o
0110 87 7f 6a 25 9d 0c ed cf a0 88 a9 04 d5 85 d1 5a ..j%...........Z
0120 6a 73 5d 55 73 2f 65 45 85 68 88 f3 ec f7 8f b9 js]Us/eE.h......
0130 16 df f5 f6 0f bd 66 31 4c d2 77 bb d6 9c 84 4f ......f1L.w....O
0140 38 f3 dd 62 c4 3c 56 e7 24 a0 e2 a5 bd 10 05 9a 8..b.<V.$.......
0150 fa 88 50 d1 e6 20 27 76 15 27 87 f8 7a f4 93 ed ..P.. 'v.'..z...
0160 54 c7 1e 33 15 48 46 e4 a0 de b0 99 6c 3e 5f b3 T..3.HF.....l>_.
0170 cb ea 56 28 e2 b4 fe c4 95 d6 42 6c b7 66 f8 f4 ..V(......Bl.f..
0180 06 55 32 54 76 ef dd 98 cc d1 3c a8 82 bc 2a 51 .U2Tv.....<...*Q
0190 a2 eb f6 c1 f0 fe 73 38 12 e3 e8 5a 8b 4e 89 80 ......s8...Z.N..
01a0 2c df d1 9d 95 09 57 12 60 0a 72 e1 a9 09 c7 6b ,.....W.`.r....k
01b0 16 de 3e 2f f8 f6 2f 19 6b c7 59 00 f4 1d 1c 15 ..>/../.k.Y.....
01c0 8c b4 04 b0 90 6d 27 89 09 ca c2 0a ee c9 d9 85 .....m'.........
01d0 49 ff 7e b8 1c 7a 64 2a 83 6e 13 da 4e df 6d 0f I.~..zd*.n..N.m.
01e0 ed 86 6b 54 aa fd b2 84 51 56 fd b4 99 7e 48 08 ..kT....QV...~H.
01f0 f9 e7 78 a9 24 fc ..x.$.
Decrypted SSL data (387 bytes):
0000 47 45 54 20 2f 66 61 76 69 63 6f 6e 2e 69 63 6f GET /favicon.ico
0010 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a HTTP/1.1..Host:
0020 20 77 77 77 2e 65 78 61 6d 70 6c 65 2e 63 6f 6d www.example.com
0030 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f ..User-Agent: Mo
0040 7a 69 6c 6c 61 2f 35 2e 30 20 28 4d 61 63 69 6e zilla/5.0 (Macin
0050 74 6f 73 68 3b 20 49 6e 74 65 6c 20 4d 61 63 20 tosh; Intel Mac
0060 4f 53 20 58 20 31 30 2e 39 3b 20 72 76 3a 33 35 OS X 10.9; rv:35
0070 2e 30 29 20 47 65 63 6b 6f 2f 32 30 31 30 30 31 .0) Gecko/201001
0080 30 31 20 46 69 72 65 66 6f 78 2f 33 35 2e 30 0d 01 Firefox/35.0.
0090 0a 41 63 63 65 70 74 3a 20 74 65 78 74 2f 68 74 .Accept: text/ht
00a0 6d 6c 2c 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 ml,application/x
00b0 68 74 6d 6c 2b 78 6d 6c 2c 61 70 70 6c 69 63 61 html+xml,applica
00c0 74 69 6f 6e 2f 78 6d 6c 3b 71 3d 30 2e 39 2c 2a tion/xml;q=0.9,*
00d0 2f 2a 3b 71 3d 30 2e 38 0d 0a 41 63 63 65 70 74 /*;q=0.8..Accept
00e0 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 2d 55 53 -Language: en-US
00f0 2c 65 6e 3b 71 3d 30 2e 35 0d 0a 41 63 63 65 70 ,en;q=0.5..Accep
0100 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 t-Encoding: gzip
0110 2c 20 64 65 66 6c 61 74 65 0d 0a 43 6f 6e 6e 65 , deflate..Conne
0120 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 ction: keep-aliv
0130 65 0d 0a 49 66 2d 4d 6f 64 69 66 69 65 64 2d 53 e..If-Modified-S
0140 69 6e 63 65 3a 20 46 72 69 2c 20 30 39 20 41 75 ince: Fri, 09 Au
0150 67 20 32 30 31 33 20 32 33 3a 35 34 3a 33 35 20 g 2013 23:54:35
0160 47 4d 54 0d 0a 49 66 2d 4e 6f 6e 65 2d 4d 61 74 GMT..If-None-Mat
0170 63 68 3a 20 22 33 35 39 36 37 30 36 35 31 22 0d ch: "359670651".
0180 0a 0d 0a ...
Changing any of the following HTTP options away from their default results in
this traffic being decoded as HTTP:
http.desegment_headers
http.desegment_body
http.dechunk_body
http.tcp.port
http.ssl.port
This does seem to be limited to http options, I tried setting a few IPv6
options away from their default but there was no change in tshark output for
this packet.
Adding in an SSL Decrypt rule using the RSA keys list for any traffic, even if
there is no such traffic in the capture, will also cause tshark to decode this
as HTTP traffic.
I have attached the capture file and keyfile that I used for this. If there is
any other information I can provide to help troubleshoot this please just let
me know.
Thank you!
You are receiving this mail because:
- You are watching all bug changes.