Increasingly often, what you need to debug is a TLS connection. However, that can make debugging more difficult as the contents of the connection are encrypted.
However, if you can access the server key, whether you have access to the production server, or are working in a development environment, or you MITM yourself with mitmproxy, or you're working on some product that ships the same default server keys with every install, you can load the key into Wireshark and then decrypt all of the TLS traffic.
To do so, go to Preferences > Protocols > SSL, and click "Edit" next to "RSA keys list". Then you can load private keys in, and associate them with a host and port, and when you have a TLS connection on that host and port, Wireshark will decrypt the traffic and you can see the inner protocol.
Note that this doesn't work if you use a cipher suite with forward secrecy, though it looks like there is support for that as well if you enable logging of ephemeral keys in your client or server (https://security.stackexchange.com/questions/35639/decryptin...)
Sometimes I find it convenient to redirect traffic with iptables. That way, if I can classify which traffic interests me, only that traffic will pass through the proxy for inspection. A warning though, SSL specific problems tend to go away when being looked at that way :).
A third method I know people use is LD_PRELOADing a hook in the application to dump keys (search for sslkeylog.c for an example) but that's far too exciting for me to try in production. Between these three methods I tend to reach for the proxy first.
Crazy useful for sending server side errors to mobile apps to simulate failure that otherwise wouldn't be replicable on demand in a production environment.
That's what test suites are for.
* To analyze the bluetooth protocol for a smartwatch so I could reverse-engineer a phone app to talk to it
* To intercept a temperature logger's TCP comms and figure out how it talked to the vendor's (crap) server software so I could write a better server for it
* To track down a weird problem where ffmpeg won't stream from my home CCTV system (it turns out it sends a duplicate PLAY command, still haven't figured out why yet...)
* To snoop for IP addresses on my local network in order to find lost devices (eg. when someone else set a device to a static IP address which has since been lost).
It's basically a fantastic Swiss Army knife for any question that starts with "what" and ends with "on the network".
That was a fun support ticket.
My personal pain point is lack of localhost tracing under Windows.
Loopback Packet Capture: Npcap is able to sniff loopback packets (transmissions between services on the same machine) by using the Windows Filtering Platform (WFP). After installation, Npcap will create an adapter named Npcap Loopback Adapter for you. If you are a Wireshark user, choose this adapter to capture, you will see all loopback traffic the same way as other non-loopback adapters
You can use Dreamscene for Windows 7/8. On Windows 10, I used VideoPaper, a free tool from https://www.reddit.com/r/VideoPaper/. It hasn't been updated in a while, so it might not work anymore. Apparently, you can also use VLC to set a video as your desktop background.
Generating a sequence diagram of a running system w a bit of Clojure code and PlantUML mixed in.
EDIT: It appears that the website has changed, but still comments about installing from the PPA for newer packages. PPAs tend to be for Ubuntu only, and is not meant for other Debian-based distros.
My greater concern with recommending that is PPA's may not be by the official folks, and PPA's tend to be for Ubuntu rather than Debian, resulting in a "FrankenDebian" (https://wiki.debian.org/DontBreakDebian), and while that PPA seems to be run by the official devs, PPAs can be set up by anyone, which runs into the whole concern of blindly trusting other's code on your system.
EDIT: Here is what the official Debian website says on it: https://wiki.debian.org/DebianSoftware#Footnotes (Footnote 1).
You should either use Debian Stable with "stable-updates" or use Debian Sid if you want the latest stuff.
I especially tend to install it (or upgrade to it) on servers during freeze time.
One user described the releases this way: "Stable is never broken; Unstable is immediately fixed; Testing is neither" .
A Debian developer seemingly agreed, responding "That's because some things might break in testing during migration. E.g., when we upload a new major release of something like MATE and half of the packages take a bit longer to migrate to testing, you end up with half of the packages of MATE in testing on the old major version and the other half being on
the new major version.
This will definitely break" .
Chris Lamb also seemed to agree, asking the user why he had not considered Unstable over Testing .
Telling people to run a new OS in order to get an updated version of Wireshark is crazy.
If people only want a single updated package, then it is perfectly fine to include the updated PPA.
If you really want the updated package, I would recommend compiling from source.
EDIT: I should point out that have a valid point that if you want to run up to date software, Debian is probably not the Distro you want to use. Ubuntu is a Debian based Distro that tends to have more up to date software. However, I like using Debian as I rarely need the most up to date software, and I have never had an update go bad on Debian.
I totally get that a FrankenDebian type of system can result from mixing packages from outside of Debian with a base Debian system.
What I really wanted to convey was that saying someone should run Debian unstable or some other OS in order to update a single package is not reasonable - that it is far more reasonable for a person to take point updates using a PPA in such a case.
However, Debian Stable is not the distro you want to run if you want the latest packages. I think Ubuntu and Arch are two distros that do that more? I have not looked around for new distros in several years, Debian is my OS of choice.
It's not guaranteed to work, but for end user facing software that nothing else links to, like Wireshark, it's likely to be completely fine. But no guarantees.
The search term is probably "apt pinning" but it's also in the Debian Wiki.
If you find that you'd rather rebuild the latest source package, you can rebuild the latest source package (apt build-dep will even install the build environment for you) and all the Debian specific patches will be included.
e.g. excludes port 22/53
ssh root@host tcpdump -U -s0 'not port 22 and not port 53' -w - | wireshark -k -I -
You can achieve the same under Windows using putty/plink:
plink.exe -ssh -pw password root@host "tcpdump -ni eth0 -s 0 -w - not port 22" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -
Of course you need to have tcpdump as a command line executable in the host.
What is it? In short, it shows you the TCP packets as opposed to the raw IP packets. If you are doing protocol analysis or debugging, it's AMAZING!
Heck, It's been many times that I've told a customer "you've got this device running this OS in your network doing DPI/ALG/etc and it's probably sitting points at the network diagram exactly here, which you conveniently forgot to add to the diagram" just by looking at a network trace with Wireshark.
I think anyone who has ever had to troubleshoot networking issues can attest to that. I certainly can. ;-)
I used it a lot to generate csv files with relevant packet data.
Classic MiTM, well known, but still freaky to observe how easy it is to set up.
Of course, this only works on machines you're the admin of, which is why it's allowed.
Our Node Proxy was not cooperating and it helped us track down the issues. Nice tool to have in your belt.
Thanks for sharing.
The one problem I have is that usually when I discover I need to use Wireshark, I'm not able to download it as I don't have an internet connection.
Solution: carry a fresh version for all platforms on a pendrive, in your wallet.
checked to see if system cleanup and hardened firewall kicked them out. After some days with zero traffic (minus broadcast etc) declared red alert over.
Filter syntax is a headache, though, if I remember correctly it's totally different for capture and display. I have to go to the manual every time I use wireshark.
Another thing that helps is to just write a display filter expression, like 'tcp.port eq 443 and ip.dst==126.96.36.199'
The most common method is to use a managed switch to setup a mirror port. Basically you tell the switch to copy all traffic and send it out on an extra port and then capture traffic while connected to that port.
I personally use a hub. You are limited to 10 or 100 Mbps (no gigabit hubs exist). I typically am debugging embedded systems, so inserting a hub into the mix is trivial and easier than trying to login to a managed switch. No tracing in the data closet or calls to IT required.
-Used it to discover Cisco switch port number and switch names for ports
-Find rouge routers on the network people setup in their dorm rooms that would hand out their own ip address(DHCP) on our network
The fix/fast protocol plugin is something I'd have been in a lot of trouble without in my past.