The threat and defense of packet sniffing [2026] — understand it with Wireshark and neutralize it with TLS everywhere

Many network attacks ultimately arrive at "reading the traffic." Seizing the path with ARP spoofing, hijacking DNS, breaking into a session — the purpose of all of them is to peek at or rewrite the information that flows. This article handles that "read" phase = packet sniffing and concludes the network-pentest cluster.

That said, the flagship sniffing tool Wireshark is both an attack tool and an essential blue-team (defense-side) tool. Visualizing "whether plaintext remains in our company's traffic" and "who this app is talking to about what" — this is the starting point of defense. This article proceeds from the viewpoint of using Wireshark as a defense tool and neutralizing sniffing with TLS.

Thoroughness of the safe zone: intercepting others' traffic with Wireshark is a violation of the secrecy of communications. All captures in this article are limited to your own machine's traffic, traffic between your own VMs in an isolated lab, or a scope authorized in writing. Peeking at "other people's packets" on public Wi-Fi or a corporate LAN clearly violates the Unauthorized Access Act and the Telecommunications Business Act. Always read the legal article first.

1. Why sniffing succeeds — the defenselessness of plaintext

Data flowing over the network is readable as-is unless encrypted. The problem is that plaintext protocols are still in active service.

With plaintext protocols, a sniffer on the path can effortlessly obtain login info, session tokens, and personal data. Moreover, since sniffing is passive (just copy and read packets), it leaves no trace for sender or receiver, making it extremely hard to detect — that's the tricky part.

1.1 "Switched, so safe" isn't true

"In a switched environment, unicast only reaches the destination, so you can't sniff" — this is only half true. If you twist the path toward yourself with ARP spoofing, even in a switched environment the traffic passes through the attacker. Sniffing doesn't complete on its own; it appears as the "read the spoils" phase of MITM. So think of sniffing defense as one with MITM defense.

2. Use Wireshark as a "defensive eye"

Wireshark shows its true value in the legitimate use of analyzing your own traffic. Let's check with your own eyes whether your app is leaking plaintext.

2.1 Audit "whether plaintext remains" on your own assets

# 自分のホストのインターフェースで、平文 HTTP（443でなく80）が流れていないか確認
# ※自分の通信のみ。フィルタは Wireshark の表示フィルタにも使える
#   tcp.port == 80                ← 平文 HTTP が残っていれば赤信号
#   http.authorization            ← 平文の認証ヘッダが見えたら重大
#   ftp || telnet                 ← そもそも使っていないか

Look at http.request in Wireshark's display filter and confirm whether all traffic to your service rides on 443 (TLS). If credentials or tokens are visible on tcp.port == 80, that's a design flaw. The "plaintext inventory" is the most valuable work for the defense side using Wireshark.

2.2 The TLS contents are (if correctly configured) unreadable

If you do the same communication over TLS, what's visible in Wireshark is up to the TLS handshake (which server, which cipher suite), and the application data is ciphertext. This is the fundamental answer to sniffing.

Note: Wireshark can decrypt TLS and see the contents when you hold the key (your own traffic, with your browser/app's keys exported via SSLKEYLOGFILE). This is a feature for debugging your own traffic; it doesn't mean you can decrypt others' TLS.

3. The main defense: TLS everywhere

The answer to sniffing, taken to its core, is one — encrypt all traffic (TLS everywhere). Even if the path is seized, if only ciphertext is readable, sniffing becomes meaningless.

3.1 "Force" the HTTP→HTTPS upgrade — HSTS

Even with TLS in place, if the first access is HTTP, that one move is targeted by SSL stripping. With HSTS (HTTP Strict Transport Security), force the browser to "always HTTPS for this site" and don't let a plaintext connection happen at all.

// Next.js / Node：HSTS で HTTPS を強制（preload まで行うと初回から HTTPS 固定）
// 値の意味：2年間・サブドメイン含め・preload リストに登録可能
const SECURITY_HEADERS = {
  "Strict-Transport-Security": "max-age=63072000; includeSubDomains; preload",
} as const;

// Next.js の next.config.ts なら headers() で全レスポンスに付与する
export const headers = async () => [
  { source: "/(.*)", headers: Object.entries(SECURITY_HEADERS).map(([key, value]) => ({ key, value })) },
];

3.2 Forward secrecy (PFS) — "even if the key leaks in the future, protect the past"

A sniffer saves the ciphertext and, if they later obtain the server's private key, decrypts it retroactively — to prepare for this "harvest now, decrypt later" attack is forward secrecy (Perfect Forward Secrecy). Because a throwaway key is exchanged per session, even if a long-term key leaks, past sessions can't be decrypted. TLS 1.3 makes PFS standard and retired non-PFS key exchange. Using TLS 1.3 itself ensures PFS.

import tls from "node:tls";

// サーバー側：TLS 1.3 を最低バージョンに（PFS 標準・古い脆弱な暗号スイートを排除）
const server = tls.createServer({
  minVersion: "TLSv1.3", // 1.2 以下の既知の弱点と非PFS鍵交換を構造的に排除
  // cert/key は環境変数や Secrets Manager 経由で注入（ハードコード厳禁）
});
server.on("error", (e) => console.error("tls server error:", e.message));

3.3 Encrypt internal traffic too — mTLS and zero trust

"HTTPS outward, plaintext internally" — this is the most common blind spot. MITM succeeds most easily within the internal network. If you encrypt and mutually authenticate service-to-service communication with mutual TLS (mTLS), sniffing becomes meaningless even if the inside is breached. This is the implementation of the core of zero trust stated in the ARP article — "don't make network location the basis of trust."

4. The defensive operations checklist

• Does all of your company's traffic ride on TLS (confirm with Wireshark that no secrets flow on tcp.port == 80).
• Have you set HSTS (preload recommended) so plaintext connections don't happen.
• Is the server's minimum TLS version 1.3 (at least 1.2), with weak cipher suites excluded.
• Do you encrypt and mutually authenticate internal / service-to-service communication with mTLS.
• Is DNS also encrypted with DoH/DoT to prevent browsing-history leakage.
• Do you operate automatic certificate renewal and revocation monitoring (an expired TLS cert invites a regression to plaintext).
• Have you not disabled TLS certificate verification (detect rejectUnauthorized: false slipping in via CI).

5. Summary — and the conclusion of the whole cluster

• Packet sniffing is passive and leaves little trace. Plaintext protocols (HTTP/FTP/Telnet) pass credentials and personal data straight through.
• Sniffing succeeds via MITM even in a switched environment. Sniffing chains with other attacks as the "read" phase.
• Wireshark is a defensive eye: a legitimate, essential skill for auditing "whether plaintext remains" on your own assets.
• The main defense is TLS everywhere: encryption (unreadable) + HSTS (no regression to plaintext) + PFS/TLS 1.3 (protect the future too) + mTLS (don't trust the inside either).

And the conclusion running through this entire network-pentest cluster is this — even though attack techniques are diverse from L2 to L4, the defenses that work converge on a surprisingly small number of principles (encryption, cryptographic verification, zero trust, minimization). Only those who understand the attackers' methods one by one can place these few principles in the right spots at the design stage. Understanding offense connects directly to defensive design — this is the real reason to learn attack techniques.

I (Hinata Tomoda) have implemented TLS-everywhere conversion of production systems (HSTS, TLS 1.3, automatic certificate renewal), service-to-service mTLS, and the inventory and eradication of plaintext communication. "I want to diagnose whether plaintext communication remains internally," "I want to implement zero trust with mTLS," "I want to inventory whether the TLS settings are outdated" — I diagnose such "render sniffing meaningless" designs from the attacker's perspective and cure them with the two wheels of encryption and verification. Feel free to reach out.