The Test Sample for the (Imaginary or Not) Bug
(No. 0) No. 1 No. 2 No. 3 No. 4
This page is work on data posted in the previous page.
(Presuming you downloaded the files linked from the previous page and ran tshark-streams.sh and tshark-hosts-conv.sh lines given there), looking up these
(lines in many of the pastes below are often broken/wrapped so they fit in the page)
$ cat pg2/dump_170317_0928_g0n-frame-http-request-full_uri.txt ... 1070 https://git.devuan.org/users/sign_in $
and:
$ cat pg2/dump_170317_0928_g0n.POST Frame 1070: 812 bytes on wire (6496 bits), 812 bytes captured (6496 bits) on interface 0 Interface id: 0 (any) Encapsulation type: Linux cooked-mode capture (25) Arrival Time: Mar 17, 2017 09:29:16.431136240 CET [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1489739356.431136240 seconds [Time delta from previous captured frame: 0.301419255 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 33.105837782 seconds] Frame Number: 1070 [...] Linux cooked capture [...] Internet Protocol Version 4, Src: 192.168.1.4, Dst: 78.26.97.141 [...] Transmission Control Protocol, Src Port: 57494 (57494), Dst Port: https (443), Seq: 1737, Ack: 242700, Len: 744 Source Port: 57494 (57494) Destination Port: https (443) [Stream index: 1] [...] Secure Sockets Layer TLSv1.2 Record Layer: Application Data Protocol: http-over-tls Content Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 739 Encrypted Application Data: 0000000000000003ca3a80409386303f6ded0506d4a090bd... Hypertext Transfer Protocol POST /users/sign_in HTTP/1.1\r\n [Expert Info (Chat/Sequence): POST /users/sign_in HTTP/1.1\r\n] [POST /users/sign_in HTTP/1.1\r\n] [Severity level: Chat] [Group: Sequence] Request Method: POST Request URI: /users/sign_in Request Version: HTTP/1.1 Host: git.devuan.org\r\n User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.9) Gecko/20100101 Goanna/3.2 Firefox/45.9 PaleMoon/27.2.0a1\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 [...] [Full request URI: https://git.devuan.org/users/sign_in] [HTTP request 3/3] [Prev request in frame: 1048] File Data: 208 bytes HTML Form URL Encoded: application/x-www-form-urlencoded Form item: "utf8" = "✓" Key: utf8 Value: \342\234\223 Form item: "authenticity_token" = "pVLNFCnViQgCr6YpzmpMIoE3vYj0oHOTCCEtbhgsDxUAYqx0EjoJVbozbZk1AuYkKGJ+HykYSulFt+TgouqsTA==" Key: authenticity_token Value: pVLNFCnViQgCr6YpzmpMIoE3vYj0oHOTCCEtbhgsDxUAYqx0EjoJVbozbZk1AuYkKGJ+HykYSulFt+TgouqsTA== Form item: "user[login]" = "miroR" Key: user[login] Value: miroR Form item: "user[password]" = "fakepassword" Key: user[password] Value: fakepassword Form item: "user[remember_me]" = "0" Key: user[remember_me] Value: 0 $
[Looking at these] we can see lots of beautiful data. I can't help but very much appreciate the Libre software used by Git Devuan! It's so clean, so friendly, so honest, so open and inviting to the user, in comparison to some... But this page is not about that.
It's all undeniably consistent, from every angle...
$ cat pg2/dump_170317_0928_g0n.hosts [...] 78.26.97.141 git.devuan.org $
Also:
$ cat pg2/dump_170317_0928_g0n.hosts IPv4 Conversations Filter:| <- | | -> | | Total | Relative | Duration | | Frames Bytes | | Frames Bytes | | Frames Bytes | Start | | 78.26.97.141 <-> 192.168.1.4 310 32342 562 790854 872 823196 12.348415503 31.4057 81.2.237.32 <-> 192.168.1.4 6 456 6 650 12 1106 12.146755194 0.2008 192.168.1.1 <-> 255.255.255.255 0 0 10 5920 10 5920 2.973310154 27.0127 0.0.0.0 <-> 255.255.255.255 0 0 9 3718 9 3718 0.082465546 29.8945 $
The line with 81.2.237.32 conversation is just the little DNS getting that was necessary (that's OpenNIC, duckduckgo.com for it). With Palemoon you are not overwhelmed with getting all your state over to any clouds for "self-repair" or such
(
the "Firefox/45.9 PaleMoon/27.2.0a1" further above is the testing, bleeding edge
Palemoon installation via git with Gentoo portage
)...
The third line is the commie Chinese router that you get in some 80% of cases when you switch to fiberoptic in Croatia. I wrote about it in:
https://github.com/miroR/uncenz/blob/master/dump_strings_ORIG2FAKE.ls-1 (search for: "ZTE ZXDSL 931VII is a censor-ready Chinese router")
Anyway, not all this talk is necessary, of course, to test if that (imaginary or real that it be) bug in Wireshark will show with this capture or not. So, a separator is in order, it's start of real talk next.
---
What did the dump_170317_0928_g0n-frame-http-request-full_uri.txt say?
1070 https://git.devuan.org/users/sign_in
That the packet ("Frame") holding my login, or sign_in credentials was Frame 1070.
And what did dump_170317_0928_g0n.POST say about that packet. It said:
Value: miroR Form item: "user[password]" = "fakepassword"
that I was user miroR, attempting to log in with password, ah, this is why I couldn't log in, as you probably saw from the screencast. I set my password deliberately to what wasn't my real password, so I could post all of this, as the Wireshark guy suggested they needed.
Also if you grep the streams extracted, you will get:
$ grep -ra fakepassword tStreams/ tStreams/dump_170317_0928_g0n_s001-ssl.bin:utf8=%E2%9C%93&authenticity_token= pVLNFCnViQgCr6YpzmpMIoE3vYj0oHOTCCEtbhgsDxUAYqx0EjoJVbozbZk1AuYkKGJ%2BHykYSulFt%2BTgouqsTA%3D%3D &user%5Blogin%5D=miroR&user%5Bpassword%5D=fakepassword&user%5Bremember_me%5D=0HTTP/1.1 200 OK tStreams/dump_170317_0928_g0n_s001-ssl.txt:utf8=%E2%9C%93&authenticity_token= pVLNFCnViQgCr6YpzmpMIoE3vYj0oHOTCCEtbhgsDxUAYqx0EjoJVbozbZk1AuYkKGJ%2BHykYSulFt%2BTgouqsTA%3D%3D &user%5Blogin%5D=miroR&user%5Bpassword%5D=fakepassword&user%5Bremember_me%5D=0
tStreams/dump_170317_0928_g0n_s001-ssl.bin and tStreams/dump_170317_0928_g0n_s001-ssl.txt are the same decrypted SSL conversation of the first stream, just one in binary (good for extracting) and the other in text (good for viewing in an editor).
That's only expected, since:
$ cat pg2/dump_170317_0928_g0n.POST [...] [Stream index: 1] [...] $
What was the frame.time_relative of that packet?
[Time since reference or first frame: 33.105837782 seconds]
It was 33.105837782
Now we can construe the filtering commands that will or will not show the (suspected) bug.
But first, I reverted to (actually re-updated to)
$ wireshark --version Wireshark 2.2.5 (wireshark-2.2.5) [...] Compiled (64-bit) with Qt 5.7.1, with libpcap, with POSIX capabilities (Linux), with libnl 3, with GLib 2.50.3, with zlib 1.2.11, with SMI 0.5.0, without c-ares, with Lua 5.1.5, with GnuTLS 3.5.10, with Gcrypt 1.7.6, without Kerberos, without GeoIP, with QtMultimedia, without AirPcap. Running on Linux 4.9.13-hardened-r1-170310_23, with locale en_GB.utf8, with libpcap version 1.8.1, with GnuTLS 3.5.10, with Gcrypt 1.7.6, with zlib 1.2.11. AMD Phenom(tm) II X4 965 Processor Built using gcc 5.4.0. $
So, being the frame.time_relative in the title of that thread on Wireshark, I have to filter out on it first:
$ tshark -o "ssl.keylog_file: dump_170317_0928_g0n_SSLKEYLOGFILE.txt" -r \
dump_170317_0928_g0n.pcap -Y \
'(!(frame.time_relative == 33.105837782))' \
-w dump_170317_0928_g0n_noPWft.pcap
(noPWft is for noPassWord_frame_time)
And if I now run (preferably in a separate directory)...
NOTE: you are probably better off downloading (see below) and running first
$ ./dump_170317_0928_g0n_noPWft_TEST1.sh
and then
$ ./dump_170317_0928_g0n_noPWft_TEST2.sh
...but I'll explain the procedure anyway:
$ mkdir dump_170317_0928_g0n_noPWft.d $ cp -iav dump_170317_0928_g0n_noPWft.pcap dump_170317_0928_g0n_noPWft.d/ $ cp -iav dump_170317_0928_g0n_SSLKEYLOGFILE.txt dump_170317_0928_g0n_noPWft.d/ $ cd dump_170317_0928_g0n_noPWft.d
First rename the script (the tshark-hosts-conv.sh needs same naming scheme for both args, and is still a little broken)
$ mv -iv dump_170317_0928_g0n_noPWft.pcap dump_170317_0928_g0n.pcap
...[And if I now run], but I didn't go all the way, I issued Ctrl-C after I got the dump_170317_0928_g0n-frame-http-request-full_uri.txt:
$ tshark-hosts-conv.sh -r dump_170317_0928_g0n.pcap -k \ dump_170317_0928_g0n_SSLKEYLOGFILE.txt
and
$ mkdir tStreams $ cp -iav dump_170317_0928_g0n.pcap tStreams/ $ cp -iav dump_170317_0928_g0n_SSLKEYLOGFILE.txt tStreams/ $ cd tStreams $ tshark-streams.sh -r dump_170317_0928_g0n.pcap -k \ dump_170317_0928_g0n_SSLKEYLOGFILE.txt
...Well, I can definitely see the issues I reported to Wireshark ML. The frame.time_relative == 33.105837782 which belongs to the frame that I want to remove is gone, but the that frame is given a different --not its own, so wrong-- frame.time_relative, and that frame --that packet-- still remains, while some other frame is removed, and not the one that the command asked to be removed.
Let's see what I will get if I filter out the frame.number with the password.
$ tshark -o "ssl.keylog_file: dump_170317_0928_g0n_SSLKEYLOGFILE.txt" -r \
dump_170317_0928_g0n.pcap -Y \
'(!(frame.number == 1070))' \
-w dump_170317_0928_g0n_noPWfn.pcap
(noPWfn is for noPassWord_frame_number)
And if I now run (preferably in a separate directory; below it's just PWft changes to PWfn from the line further above)...
NOTE: you are probably better off downloading (see below) and running first
$ ./dump_170317_0928_g0n_noPWfn_TEST1.sh
and then
$ ./dump_170317_0928_g0n_noPWfn_TEST2.sh
...but I'll explain the procedure anyway:
$ mkdir dump_170317_0928_g0n_noPWfn.d $ cp -iav dump_170317_0928_g0n_noPWfn.pcap dump_170317_0928_g0n_noPWfn.d/ $ cp -iav dump_170317_0928_g0n_SSLKEYLOGFILE.txt dump_170317_0928_g0n_noPWfn.d/ $ cd dump_170317_0928_g0n_noPWfn.d
First rename the script (the tshark-hosts-conv.sh needs same naming scheme for both args, and is still a little broken)
$ mv -iv dump_170317_0928_g0n_noPWfn.pcap dump_170317_0928_g0n.pcap
...[And if I now run], but I didn't go all the way, I issued Ctrl-C after I got the dump_170317_0928_g0n-frame-http-request-full_uri.txt:
$ tshark-hosts-conv.sh -r dump_170317_0928_g0n.pcap -k \ dump_170317_0928_g0n_SSLKEYLOGFILE.txt
and
$ mkdir tStreams $ cp -iav dump_170317_0928_g0n.pcap tStreams/ $ cp -iav dump_170317_0928_g0n_SSLKEYLOGFILE.txt tStreams/ $ cd tStreams $ tshark-streams.sh -r dump_170317_0928_g0n.pcap -k \ dump_170317_0928_g0n_SSLKEYLOGFILE.txt dump_170317_0928_g0n_SSLKEYLOGFILE.txt
I will still find the password in all the places as previously.
---
The (current) list of files that you might find useful for this study are listed in:
pg3/dump_170317_0928_g0n_noPWfn_TEST1.sh pg3/dump_170317_0928_g0n_noPWfn_TEST2.sh pg3/dump_170317_0928_g0n_noPWft_TEST1.sh pg3/dump_170317_0928_g0n_noPWft_TEST2.shwhich verify to: ls-1pg3.sum signed by: ls-1pg3.sum.asc
You might find dump_dLo.sh script from my uncenz program more useful then downloading each file separately.
BTW, it'd be even more work to demonstrate what filters wrong in my Wireshark without these (very clumsy and unpolished --and unfinished, the second one-- sets of scripts):
