Day three of the ReDI Cybersecurity course and it was one of the most packed sessions yet — Wireshark front and centre, surrounded by a parade of protocols spanning every layer of the stack. Protocols I had only ever read about were suddenly right there in front of me, dissected packet by packet. Seeing it all live, in real captured traffic, was something else entirely. This post is my attempt to make sense of everything we covered, with some reflections on what surprised me and what I'm still turning over in my head.

Wireshark — Reading the Wire

Wireshark is a free, open-source packet analyser — arguably the most important tool in a network security analyst's kit. It captures all traffic passing through a network interface and lets you dissect it layer by layer, right down to the raw bytes. Think of it as a microscope for network communication.

What makes Wireshark so powerful for security work is that it doesn't lie. Logs can be manipulated, firewalls can be misconfigured, but a raw packet capture shows you exactly what travelled across the wire. If something is wrong, the truth is in there.

Key Wireshark skills we practised

DHCP — Dynamic Host Configuration Protocol

DHCP is the protocol that automatically assigns IP addresses to devices when they join a network. Without it, every device would need a manually configured IP — fine for servers, impractical for hundreds of laptops and phones.

The DHCP exchange follows a four-step handshake called DORA:

  1. Discover — the client broadcasts "I need an IP address, anyone there?"
  2. Offer — a DHCP server responds with a proposed IP and lease time.
  3. Request — the client says "Yes, I'll take that IP."
  4. Acknowledge — the server confirms the assignment.

In Wireshark, looking at DHCP traffic reveals a massive amount of information: the client hostname, MAC address, requested lease duration, and the assigned gateway and DNS servers. That last point is security-relevant — a rogue DHCP server can hand out a malicious DNS server address and redirect all your traffic. This attack is called DHCP spoofing and it requires no authentication to pull off on most networks.

ARP — Address Resolution Protocol

ARP bridges the gap between Layer 3 (IP addresses) and Layer 2 (MAC addresses). When a device wants to send a packet to an IP on the same subnet, it broadcasts an ARP request: "Who has 192.168.1.10? Tell me your MAC address." The owner replies with its MAC, the sender caches the result, and communication proceeds.

ARP is famously insecure. There is no authentication — any device can broadcast a fake ARP reply and poison the cache of other hosts. This is how ARP spoofing (or ARP poisoning) works, enabling man-in-the-middle attacks on a local network. An attacker inserts themselves in the path between two hosts, relaying traffic while reading or modifying it. Wireshark makes this attack trivially visible: you'll see gratuitous ARP packets being sent that weren't requested by anyone.

ECMP — Equal-Cost Multi-Path Routing

ECMP is a network routing strategy that allows traffic to be distributed across multiple paths that have the same routing cost. Instead of sending everything down one link and keeping others as standby, ECMP sends traffic across all equally-good paths simultaneously — improving throughput and resilience.

From a security perspective, ECMP creates a challenge for monitoring: a single TCP flow's packets might travel via different physical paths. This means packet captures at a single point might only see part of the conversation, complicating analysis. It also means intrusion detection systems sitting on one path might miss half the traffic.

Routing & Routing Protocols

Routing is how packets find their path across networks. Routers consult their routing tables — built either manually (static routes) or dynamically by routing protocols. Key protocols include:

NAT — Network Address Translation & Security Concerns

NAT allows many devices using private IP addresses (e.g. 192.168.x.x) to share a single public IP when communicating with the internet. The router keeps a translation table mapping internal connections to external ones.

NAT has a side-effect that is sometimes mistaken for security: it hides internal IP addresses from the outside world. But this is not a firewall. NAT doesn't filter traffic — a firewall does. Relying on NAT for security instead of explicit firewall rules is a common and dangerous misconception. Additionally, for forensic investigations, NAT can complicate attribution because many internal hosts share the same public IP — you need timestamps and port numbers to trace back to a specific device.

DNS — Domain Name System

DNS is the internet's phonebook. When you type google.com, a DNS query goes out, and the response comes back with an IP address your device can route to. The DNS hierarchy flows from root servers → TLD servers (e.g. .com) → authoritative servers for the domain.

DNS is a prime target for attackers:

In Wireshark, DNS traffic is incredibly revealing — you can see every domain a device is querying, which builds a detailed picture of browsing habits and installed software.

Whois — The Domain Registry Database

Whois is a public database that stores registration information for domain names and IP address blocks: who registered a domain, when, the registrar used, and often contact details. It is a foundational OSINT (Open Source Intelligence) tool in cybersecurity — used in threat investigation to identify who owns a suspicious domain or IP range.

Privacy-focused registrars now mask personal details through proxy services (e.g. "Privacy Protect LLC" instead of a real name), which limits how useful Whois is for attribution. But bulk registrations of similar-sounding domains, or recently registered domains with suspicious patterns, still yield useful signals.

HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the foundation of data communication on the web. It defines how clients (browsers) request resources and how servers respond. An HTTP exchange is entirely plaintext — every header, cookie, form field, and response body is readable to anyone on the network.

HTTPS is HTTP wrapped in TLS encryption. The content is encrypted — but metadata (source, destination IP, timing, volume of traffic) is still visible, which is enough for traffic analysis even without decrypting the payload.

HTTP Protocol Versions

In Wireshark, HTTP/1 traffic is trivially readable. HTTP/2 is binary but Wireshark decodes it. HTTP/3 and QUIC over UDP require specific dissectors and are harder to analyse, which creates monitoring blind spots.

FTP & Secure File Transfer Protocols

FTP (File Transfer Protocol) is one of the oldest protocols on the internet. It transfers files between a client and a server — in completely plaintext. Username, password, and all file contents travel unencrypted. In Wireshark, you can literally follow an FTP stream and read everything.

Secure alternatives exist and should be used instead:

Reflection: If you still have FTP exposed anywhere and someone is running Wireshark on your network, your credentials are already gone. The moment you see FTP in a production environment, it should be treated as a critical finding.

Email Protocols

Email infrastructure involves a handful of protocols working together:

Email is also a primary attack vector. SMTP has no built-in authentication of the sender — that's why spam and phishing exist. Modern email security relies on SPF, DKIM, and DMARC to validate senders and detect spoofed messages. In Wireshark, unencrypted SMTP traffic reveals not just metadata but often the full email content.

TLS — Transport Layer Security

TLS is the cryptographic protocol that secures almost all modern internet traffic. It provides confidentiality (encryption), integrity (MAC), and authentication (certificates). It replaced SSL (which is now deprecated and insecure).

A TLS handshake involves:

  1. Client hello — cipher suites and TLS version offered.
  2. Server hello — cipher selected, certificate sent.
  3. Certificate verification — client validates the server's identity.
  4. Key exchange — session keys generated.
  5. Finished — encrypted communication begins.

In Wireshark, you can see the full TLS handshake in plaintext (it hasn't started encrypting yet at that point), which reveals the TLS version used, the negotiated cipher suite, and the server certificate. This is valuable for identifying outdated TLS versions (1.0, 1.1) or weak cipher suites.

SSH — Secure Shell

SSH is the standard protocol for encrypted remote access to servers. It replaced Telnet (which sent everything in plaintext) and provides a secure encrypted channel for command execution, tunnelling, and port forwarding.

In Wireshark, SSH traffic shows the connection and handshake metadata but not the content — it's encrypted. However, you can still learn things: connection timing, session duration, data volume. Unusually large SSH transfers in the middle of the night are a red flag worth investigating even if the content is encrypted.

SSH keys are also a significant attack surface. Compromised or misconfigured SSH keys (especially those with no passphrase, left on shared systems) are a common initial access vector.

SSL — Secure Sockets Layer

SSL is the predecessor to TLS. SSL 2.0 and 3.0 are both deprecated with known critical vulnerabilities (POODLE, DROWN). Any system still advertising SSL in a Wireshark capture should be treated as a vulnerability. The industry standard is TLS 1.2 at minimum, with TLS 1.3 strongly preferred.

The terms "SSL" and "TLS" are still used interchangeably in common speech (SSL certificate, SSL termination) even though technically the protocol is TLS. Worth knowing the difference when talking to security professionals.

VPN — Virtual Private Network

A VPN creates an encrypted tunnel between a client and a VPN server, hiding traffic from anyone between the two. VPNs are used for remote work (connecting to a corporate network), privacy (hiding traffic from ISPs), and bypassing geographic restrictions.

From a security monitoring perspective, VPNs are a double-edged sword. They protect legitimate users on hostile networks (e.g. public Wi-Fi), but attackers also use them to mask their true IP address and origin. In Wireshark, VPN traffic appears as encrypted blobs to the VPN endpoint — the destinations inside the tunnel are hidden. Corporate VPN deployments often use split tunnelling, where only corporate traffic goes through the VPN — understanding this topology matters for monitoring coverage.

TCP — Transmission Control Protocol

TCP is the reliable, connection-oriented transport protocol. It guarantees delivery, ordering, and error checking via a three-way handshake (SYN → SYN-ACK → ACK) before data flows. Every byte sent is acknowledged.

In Wireshark, TCP gives you:

UDP — User Datagram Protocol

UDP is the fire-and-forget protocol. No handshake, no acknowledgements, no guaranteed delivery. What you gain is speed and low overhead — ideal for DNS, streaming video, VoIP, and online gaming where a dropped packet is better than a delayed one.

UDP is also abused in UDP amplification attacks — a class of DDoS attack where an attacker spoof the victim's IP and sends small UDP requests to open servers (DNS, NTP, Memcached) that respond with much larger replies. The victim is flooded with amplified traffic it never requested.

QUIC Protocol

QUIC (Quick UDP Internet Connections) is a modern transport protocol developed by Google and standardised by the IETF. It runs over UDP but adds reliability, multiplexing, and built-in TLS 1.3 encryption. HTTP/3 is built on top of QUIC.

QUIC eliminates the round-trip delays of TCP handshakes and TLS negotiation by combining them — a connection can be established in a single round trip (or zero for returning users). This makes web applications noticeably faster, especially on lossy mobile connections.

For security analysts, QUIC presents monitoring challenges: it's encrypted by default, runs on UDP (which many firewalls don't filter as aggressively as TCP), and its connection IDs can be used to migrate across network changes. Many enterprise environments block QUIC and force browsers to fall back to HTTP/2 over TCP specifically because of these monitoring limitations.

ICMP — Internet Control Message Protocol

ICMP is the diagnostic protocol of IP networks — it's what ping uses. ICMP carries error messages (destination unreachable, TTL exceeded) and informational messages between network devices. It operates at Layer 3 alongside IP and has no port numbers.

Security relevance: ICMP is used in network reconnaissance (ping sweeps to discover live hosts) and in ICMP tunnelling, where data is hidden inside ICMP payloads to bypass firewalls that allow ping traffic. A simple Wireshark filter of icmp can reveal whether someone is actively probing your network.

SCTP — Stream Control Transmission Protocol

SCTP is a transport-layer protocol that shares properties of both TCP and UDP — it provides reliable, ordered delivery like TCP but supports multiple streams within a single connection (multi-streaming) and multiple network paths simultaneously (multi-homing). It's commonly used in telephony signalling (SS7 over IP) and some VoIP infrastructure.

SCTP is rarely seen in typical enterprise or web traffic, which is exactly why it sometimes slips past security monitoring tools that are tuned for TCP and UDP. If you see SCTP in a Wireshark capture in an unexpected environment, it warrants investigation.

Reflections on the Class

What struck me most about today was the sheer number of protocols that are still in use despite being fundamentally insecure by design — FTP, plain HTTP, SMTP without encryption, SSL. These weren't designed with attackers in mind because they were built in an era where networks were assumed to be trusted. That assumption is long dead, but the protocols are still running.

Wireshark makes this viscerally real. It's one thing to read that "FTP sends credentials in plaintext." It's another thing to click "Follow TCP Stream" and watch a complete login session appear in a pop-up window. I think every developer and network engineer should spend at least a few hours in Wireshark before ever making decisions about what protocols to deploy or what traffic to trust.

I also found myself thinking about defence in layers. No single protocol is perfectly secure in isolation — TLS doesn't help if the certificate authority is compromised; SSH doesn't help if the key pair is leaked; HTTPS doesn't help if the DNS response was poisoned before the connection was made. Security is always a stack of mitigations, not a single silver bullet.

The other thing I'm taking away: the gap between legacy protocols (FTP, HTTP/1, SSL) and modern ones (QUIC, TLS 1.3, SFTP) isn't just about performance. It's about what a defender can see, what an attacker can exploit, and what it costs to migrate. In many real-world environments, that migration cost is what keeps insecure protocols alive long past their expiry date — and that gap is exactly where attackers live.

Summary

We covered an enormous amount of ground today. Here's the one-line takeaway for each protocol: