More Capture Details II

An updated version of my Ultimate PCAP is available. It features some more network protocols that I will depict in this blog post. It’s getting more special since the most common protocols were already in there. ;)

FTP and FTPS

Definitely one of the most well-known protocols: FTP. There are three FTP sessions in the trace:

  1. Two IPv4 FTP sessions between ip.addr eq 10.82.185.11 and ip.addr eq 5.35.226.136 – one via unencrypted FTP (yes, you can see the password and the whole transferred file!), and one with TLS. I used the FileZilla version 3.50.0.
  2. One IPv6 session from a Windows 7 PC using the file explorer, which uses unencrypted FTP. Ouch. Display filter: ipv6.addr eq 2001:470:765b:0:1965:111f:4398:d558 and ipv6.addr eq 2a01:488:42:1000:50ed:8588:8a:c570 .

You have to use the IP based display filter rather than ftp or ftp-data in order to see the whole TCP handshake and TLS session. Even tcp.port in { 20 21 } is not enough due to the usage of dynamic passive ports! Sigh.

In all three sessions, I logged in, changed the directory to “/Correct Files” and downloaded the “Lorem ipsum dolor sit amet.txt” file. (Which can be found here: https://testfiles.webernetz.net/.)

Plaintext FTP incl. password
FTP using TLS

BFD

The Bidirectional Forwarding Detection protocol (RFC 5881) is used between routers to detect link failures really fast. In my trace file, you can find two routers using OSPF in conjunction with BFD. It uses UDP ports 3784 for control packets and 3785 for its echo packets. Wireshark’s display filter “bfd” will only show the control packets while “bfd_echo” will show the echo packets. You can also other filters such as udp.port in { 3784 3785 } to filter for them. (This will also show an ICMP destination unreachable port unreachable after the very first control packet which is not shown by the “bfd” filter.)

In the following screenshot, you can also see an ICMP port unreachable right after the very first control packet. To my mind, this is because the BFD neighborship was not yet established or the router sending the first control message has not yet opened the receiving port.

Wireshark BFD

The trace shows the first seconds after router reboot, captured with my ProfiShark.

Cisco IOS configuration used for this setup:

Show command:

 

OCSP Stapling

You can find some OCSP related packets in the Ultimate PCAP, divided into two parts:

  1. the OCSP requests sent from my server (Raspi that hosts random.weberlab.de and ip.webernetz.net) to the Let’s Encrypt OCSP server in order to get signed time-stamps, and
  2. some regular HTTPS connections to my Raspi, which queried the OCSP stapling in conjunction with the normal X.509 certificate.

You will find both types by using the “ocsp” display filter. Note that this does not display the whole TCP/TLS connections, but only the OCSP parts. Furthermore note, that the stapled certificate status within the TLS connection is not the OCSP protocol, but only a TLS record layer.

OCSP requests to the OCSP server, asking for signed time-stamps
OCSP stapling after the regular X.509 certificate

ACME Challenge

Ok, this is not an own network protocol but uses HTTP for its challenge. Hence it does not have an own Wireshark dissector or the like. The HTTP-01 Automatic Certificate Management Environment (ACME) protocol challenges are in plain text HTTP on port 80. I found them in a packet capture at the Raspberry Pi that hosts random.weberlab.de and ip.webernetz.net (among others). You’ll find several short HTTP sessions requesting the well-known “/.well-known/acme-challenge/<TOKEN>” path:

Wireshark ACME Challenges HTTP-01

OpenPGP HTTP Keyserver Protocol (HKP)

The keyserver protocol HKP is used to transfer OpenPGP keys to/from a keyserver. I am using it within my Enigmail plugin for Thunderbird. Actually, it’s not a real protocol but HTTP on port 11371. It even doesn’t have a Wikipedia article (as of 2020) nor an own Wireshark dissector. ;) Wireshark lists it as HTTP:

Wireshark HKP Overview

While following the TCP- or HTTP-Stream you can see the mere transfer of an OpenPGP public key:

Wireshark HKP Follow HTTP Stream

HTTPS Reconnect / Session Resumption

Again, this is not really an own protocol, but a small variance in how HTTPS aka TLS is used: with session resumption. Tested with:

Find it with display filter: ipv6.addr eq 2001:470:1f0b:16b0:221:70ff:feb2:e6c and ipv6.addr eq 2a02:2e0:3fe:1001:7777:772e:2:85:

HTTPS Reconnect / Session Resumption

mDNS

Haha, funny, I wasn’t even aware that I had mDNS packets in my trace until I stumbled upon it by accident. ;) AFAIK they were all sourced by Apple devices during my captures for AirPlay and AirPrint. Legacy IP and IPv6 traffic, sourced and destined to UDP port 5353:

Wireshark mDNS

Miscellaneous: Negative Delta Times

This is not a protocol at all, but a strange observation in Wireshark: negative delta times. What? How? Have a look at the connections between:

Wireshark measuring negative delta times

I had a little discussion on Twitter, while Sake Blok from SYN-bit finally sent me some notes about it:

It is definitely not an NTP time jumping problem as it repeatedly happens in a similar matter. From what I can tell, the remote party sends a response and a FIN packet really quickly after one-another (see packets 6 and 8). They will end up being read by the OS with the same interrupt and therefore they will be timestamped almost with the same time (2 microseconds apart, which is not physically possible on the 1Gbit/s link for a 982 byte packet, they should at least be like ~8 ms apart). From the ACK value of frame 7, it is clear it is a response to 6 only, not to 6 and 8. So libpcap is correct in putting this packet between these two frames. But apparently, this packet gets timestamped at a later time. I’m no expert on the precise inner workings of the capture mechanism. But I do know two things:
– never capture on one of the hosts if you really need to know how things look on the network
– use a dedicated capture device/NIC that does time stamping in hardware when timestamps are important (like the ProfiShark)

Thank you, Sake!

Photo by Timothy Dykes on Unsplash.

Leave a Reply

Your email address will not be published. Required fields are marked *