How Attackers Intercept Network Traffic on Copper, Fiber and Wi-Fi

Attackers read network traffic by getting access to the medium it travels over: a tap or a misused switch port on copper Ethernet, a splitter on a fiber, a radio in range of a Wi-Fi network, or a position upstream at a provider. Once they have that access, encryption decides what they learn. With TLS 1.3, encrypted DNS and WPA3 in place, an eavesdropper mostly sees who is talking to whom, when and how much, but not what is said.

This post walks through each medium, explains the techniques as concepts so defenders know what they face, and shows what each layer of encryption hides and leaves exposed. There are no attack walkthroughs here, only commands for checking your own setup. Every standard and date is checked against the IETF, IEEE, the Wi-Fi Alliance, NIST or CISA.

Key takeaways

• Interception is a two step problem. First an attacker needs access to the medium (copper, fiber, radio or an upstream network). Then encryption decides what that access is worth.
• On copper Ethernet the realistic routes are a physical tap, a switch port mirrored by someone who controls the switch, and tricks that make your traffic flow through an attacker's machine on the same LAN segment, such as ARP spoofing. ARP has no authentication, as RFC 5227 notes.
• Fiber can be tapped with optical splitters, and those devices are used lawfully every day for monitoring. The hard part for an attacker is getting physical access to the cable, not the optics.
• On Wi-Fi anyone in radio range can receive every frame. WPA2 and WPA3 encrypt the payload, but MAC addresses, network names, probe requests, frame sizes and timing stay visible.
• On a WPA2-Personal network, RFC 8110 explains that anyone who knows the shared password and sees the handshake can derive another client's traffic keys. WPA3-Personal and Wi-Fi Enhanced Open use a key exchange instead.
• TLS 1.3 (RFC 8446) hides content but, in its own words, "does not hide the length of the data". Server IP addresses, timing and, without Encrypted Client Hello (RFC 9849, March 2026), the server name stay visible.
• Defences stack by layer: TLS everywhere with HSTS, encrypted DNS, WPA3 with Protected Management Frames, 802.1X, MACsec (IEEE 802.1AE) on LAN links, IPsec or WireGuard between sites, switch hardening, locked wiring closets and monitoring for rogue access points.

The two questions behind every interception

Every interception technique answers two questions: how does the attacker get a copy of the signal, and what can they read once they have it? Teams tend to focus on the second because encryption is something they can deploy, but the first tells you where physical controls, switch hardening and monitoring belong.

RFC 7258, published in May 2014 as Best Current Practice 188, states that pervasive monitoring "is an attack" and names the techniques: passive or active wiretaps, traffic analysis using timing or packet sizes, and subverting keys. RFC 7624 (August 2015) separates a passive attacker who wants undetected eavesdropping from an active one who can also inject or modify packets. Defenders need different controls for each.

Copper Ethernet: taps, mirrored ports and LAN tricks

A switched Ethernet network sends each frame only to the port that needs it, so a computer plugged into a spare wall socket does not see everyone else's traffic by default. An attacker has to change that in one of four ways.

Physical taps on twisted pair

A network tap sits inline on a cable, passing traffic through while copying it to a monitoring port. Network teams use taps legitimately for troubleshooting and monitoring. In the wrong hands the same device is a passive wiretap that sends nothing, so the endpoints cannot detect it from the traffic. The defence is physical (conduit, locked comms rooms, inspected patch panels) plus link encryption. The IEEE's description of 802.1AE MAC Security says it directly: "it is usually not practical to secure an entire network against physical access."

Port mirroring on a compromised or misconfigured switch

Managed switches can copy the traffic of ports or whole VLANs to another port for analysis, a normal feature called port mirroring or SPAN. It becomes an interception route when someone gets switch admin rights through a weak management password, an exposed management interface, an unpatched switch OS or a stolen account. No cable needs touching, and the copy can be sent to a remote collector. RFC 7624 notes traffic can be monitored "by installing monitoring tools in Internet routers", and the same holds inside a building. Patch and log switches like servers, and alert on any change to mirror sessions.

ARP spoofing and IPv6 neighbor spoofing, as concepts

On an IPv4 LAN, the Address Resolution Protocol (ARP) maps an IP address, such as the gateway's, to a MAC address, with no authentication. RFC 5227 says a malicious host "may send fraudulent ARP packets on the network" and can easily claim "ownership of every address on the network." A laptop that believes the attacker's MAC belongs to the gateway sends its traffic there, the attacker forwards it, and both sides keep working.

IPv6 Neighbor Discovery has the same trust problem on a shared link; RFC 3756 (May 2004) catalogues redirect attacks in which a malicious node diverts packets meant for the router. The defences live in the switch: Dynamic ARP Inspection (DAI) drops ARP replies that do not match bindings learned by DHCP snooping, IPv6 first hop security features such as router advertisement guard do the same job for IPv6, and smaller VLANs shrink what any one attacker can reach.

MAC flooding

A switch stores which MAC address sits on which port in a table of limited size. MAC flooding, as a concept, fills that table with fake addresses so some switches fall back to sending traffic out of every port, like an old hub. Port security that caps learned addresses per port closes this route, and so does 802.1X, because an unauthenticated device never gets a working port.

Fiber optic cables: splitters, bends and the access problem

Fiber carries light, not electricity. That does not make it untappable; it makes tapping a physical job.

Optical splitters and bend taps

An optical splitter sends a fraction of the light in a fiber to a second output. Passive splitters are standard equipment: many fiber to the home networks use them to share one feeder fiber among customers, and operators use them to feed monitoring systems on their own links. Inserting one means breaking the fiber or using a spare patch panel connector, which usually causes a brief outage a careful operator may notice. A bend tap works differently. Fiber keeps light inside by total internal reflection, and a tight bend lets a little light escape through the side, where a detector can pick it up without cutting the fiber. The only sign is a small extra loss that optical power monitoring shows if someone is watching.

Why access to the cable is the hard part

The optics are not the obstacle; reaching the cable is. Long haul fibers run in ducts and secured buildings, data center interconnects run between guarded facilities, and submarine cables come ashore at a few landing stations. An attacker who can reach those points is usually a nation state, an insider at a carrier or colocation provider, or someone with legal authority.

RFC 7624, summarising reporting published from June 2013, describes a programme in which access to cables between large providers' data centers yielded user data because "communications among these data centers were not encrypted." Providers responded by encrypting traffic between their own sites. Treat any link you do not physically control, including leased dark fiber, as untrusted and encrypt it with MACsec, IPsec or TLS.

Wi-Fi on 2.4, 5 and 6 GHz: everyone in range is on the wire

Wi-Fi is a broadcast medium. Every frame sent on 2.4 GHz, 5 GHz or 6 GHz travels in all directions, and any radio in range on the same channel can receive it, with no tap or switch access needed. Our post on Wi-Fi generations from 802.11b to Wi-Fi 7 and Wi-Fi 8 covers how the bands and security modes evolved. Here the question is what a listener learns.

What WPA2 and WPA3 encryption hide

On a WPA2 or WPA3 network, each frame's data payload is encrypted with keys derived during the connection handshake, so a listener without those keys cannot read the web pages, DNS queries or application data inside. The Wi-Fi Alliance introduced WPA3 on 25 June 2018. It says all WPA3 networks require Protected Management Frames and disallow outdated legacy protocols, and that WPA3-Personal uses Simultaneous Authentication of Equals (SAE), "a secure key establishment protocol between devices", for stronger protection against password guessing. WPA3-Enterprise adds an optional 192-bit mode, and the Alliance's security page states WPA3 is mandatory for Wi-Fi CERTIFIED devices.

What stays visible even on a WPA3 network

Encryption covers the payload, not the envelope. A listener in range can still see:

• MAC addresses of the access point and every client, which sit in frame headers. Phones and laptops now randomise MAC addresses per network to limit tracking; our post on network card evolution and MAC randomisation explains where that falls short.
• Network names (SSIDs) in beacons, broadcast many times a second unless hidden.
• Probe requests, which can reveal names of networks a device has joined before, such as a home or hotel SSID.
• Frame sizes, timing and volume, enough to tell when a device is active and sometimes what kind of activity it is.

Protected Management Frames (IEEE 802.11w) close one gap. The Wi-Fi Alliance says PMF protects unicast management action frames from eavesdropping and forging and multicast ones from forging, and is required for all new certified devices. Without it, a forged deauthentication frame can knock a client off, which RFC 8110 notes forces the client to repeat its handshake.

Why a shared password is weaker than it looks

WPA2-Personal uses one pre-shared key (PSK), the password everyone types. RFC 8110 is blunt: because "the PSK is known by everyone", a passive attacker who knows it can observe a client's four way handshake "and compute the traffic encryption keys". So WPA2-Personal protects you from strangers, not from a guest, former employee or anyone who read the password off a café sign. WPA3-Personal's SAE and Wi-Fi Enhanced Open both run a key exchange at connection time, so knowing the password, or there being none, does not by itself let a passive listener derive another client's keys. 802.1X enterprise modes go further and give each user separate credentials.

Open networks and Wi-Fi Enhanced Open

A traditional open network sends every payload in the clear, readable by anyone in range unless TLS, a VPN or an encrypted app protects it. Wi-Fi Enhanced Open is the Wi-Fi Alliance certification of Opportunistic Wireless Encryption, RFC 8110 (March 2017): client and access point run a Diffie-Hellman exchange instead of using a public password. The Alliance calls it "unauthenticated data encryption", and RFC 8110 states it "does not provide authentication." It defeats passive listeners but not a fake access point with the same name.

Evil twin and rogue access points

An evil twin is an attacker's access point dressed up as a legitimate one. A device that connects to it hands the attacker its gateway position. NIST SP 800-153 (February 2012) calls rogue WLAN devices "particularly noteworthy": they can open a "backdoor into the wired network" and allow man in the middle attacks on clients that connect. NIST also notes that passive interception sends nothing, so "there is nothing for an organization to monitor electronically", while active attacks such as rogue APs can be found with wireless intrusion detection sensors and periodic walk throughs. On the client side, 802.1X with server certificate validation stops devices handing credentials to an impostor, and an evil twin that does not know a WPA3-Personal password cannot complete SAE.

Cellular, briefly

The radio link between a modern phone and a cell tower is encrypted, so the bigger exposures are elsewhere. Texts and ordinary calls are not end to end encrypted, so anyone with access inside a carrier's network can read or record them. Older network generations had weaker radio protections, and fake base stations, as a concept, try to push phones onto them.

CISA's Mobile Communications Best Practice Guidance, released on 18 December 2024 and updated on 24 November 2025, followed nation state targeting of commercial telecommunications infrastructure that led to theft of call records and compromise of some highly targeted people's communications. It recommends using only end to end encrypted communications and dropping SMS as a second factor because "SMS messages are not encrypted". It also warns that personal VPNs "simply shift residual risks" from the internet provider to the VPN provider, while an organisation's own VPN is a different case.

Upstream: ISPs, exchanges, submarine cables and lawful intercept

Once traffic leaves your building it crosses networks you do not control. Your internet provider sees every packet, internet exchange points concentrate many providers' traffic in one place, and RFC 7624 cites 2013 reporting that one national programme appeared to have access to around 1,500 major cables passing through a single country.

Lawful intercept is the legal version: in many countries carriers must, under national law and legal process, give authorised agencies copies of specified traffic. The IETF decided in RFC 2804 (May 2000) "not to consider requirements for wiretapping" in its standards, and RFC 7258 later argued that because the techniques are the same whatever the motive, protocols cannot defend against bad actors while allowing monitoring by others. You cannot audit every network your packets cross, but you can make sure whatever is copied is ciphertext.

What an eavesdropper sees, with and without encryption

The medium decides who gets a copy. The protocols decide what the copy is worth. The table below shows what a passive observer anywhere on the path can read for common traffic types.

Plaintext HTTP

Unencrypted HTTP gives an eavesdropper the full URL, form fields, session cookies and page content, and lets an active attacker alter pages or redirect downloads. Very little legitimate traffic should still use it.

DNS, and why it leaks even when the web traffic is encrypted

Classic DNS sends each lookup unencrypted, so an observer sees every name you resolve even if every later connection uses TLS. CISA's Encrypted DNS Implementation Guidance (May 2024) says DNS querying protocols "are still unencrypted", letting adversaries monitor or tamper with requests, and notes federal agencies were required to encrypt DNS wherever technically supported. Three IETF standards fix this: DNS over TLS (RFC 7858, May 2016) on port 853, DNS over HTTPS (RFC 8484, October 2018) and DNS over QUIC (RFC 9250, May 2022). All three hide lookups from the network, but the resolver still sees them, so use one you operate or contract for. NIST SP 800-81 Revision 3 (March 2026) covers enterprise DNS security.

TLS 1.3: content hidden, metadata not

TLS 1.3, RFC 8446 (August 2018), protects content and integrity and encrypts more of the handshake than before, including the server certificate. Its introduction is candid: "TLS does not hide the length of the data it transmits", though endpoints can pad records. An observer still sees IP addresses, ports, record sizes and timing, and, without Encrypted Client Hello, the server name. Traffic analysis uses exactly those signals, so plan for metadata to be visible and make sure content and credentials are not.

SNI and the status of Encrypted Client Hello

The Server Name Indication extension tells a server which site the client wants. RFC 8744 (July 2020) notes SNI "is carried in cleartext in the TLS ClientHello message" and that monitoring shifted to it as other methods were blocked. Encrypted Client Hello was published as RFC 9849 in March 2026. It encrypts the inner ClientHello, including the real server name, under a key the server publishes in DNS, while an outer ClientHello carries a shared public name. The RFC warns that "ECH is not in itself sufficient to protect the identity of the server", because plaintext DNS or a single site IP address can still leak it. Support varies by browser, server and host, so check your own stack.

QUIC, TCP and UDP

TCP and UDP are transport protocols and neither encrypts anything by itself; a plain packet shows its ports, header fields and payload. What matters is what runs on top. QUIC, RFC 9000 (May 2021), runs over UDP with TLS 1.3 built in, encrypts most of its transport header, and applies header protection so packet numbers "cannot be used to correlate activity", though the RFC adds that timing and size still can be. With TLS over TCP, the TCP headers stay in the clear.

VPNs: moving the trust, not removing it

A VPN tunnels your traffic to an endpoint. IPsec (RFC 4301, December 2005) works at the IP layer and dominates site to site links; WireGuard aims, per its project site, to be "as easy to configure and deploy as SSH". The local network and your provider see only encrypted packets to the endpoint, while the endpoint and everything after it see your traffic. Use a VPN when you control the endpoint or trust its operator more than the local network, and keep TLS inside it.

A dated timeline of the standards that closed these gaps

Defences, layer by layer

No single control stops interception on every medium. The useful approach is to decide, for each kind of traffic, who might get a copy and which layer will make that copy useless.

TLS everywhere and HSTS

Encrypt every connection worth protecting, including internal service to service traffic; the data center cable example above is what trusting the internal network costs. NIST SP 800-52 Revision 2 (August 2019) requires federal TLS servers and clients to support TLS 1.2 with approved cipher suites and required TLS 1.3 support by 1 January 2024, a sound baseline for anyone. HSTS, RFC 6797 (November 2012), tells browsers to use HTTPS only on future visits, which defeats downgrades to plain HTTP. The RFC names its one gap, a "Bootstrap MITM Vulnerability" on the first visit, which browser preload lists close for sites that opt in.

Encrypted DNS, WPA3 and 802.1X

Turn on DoH or DoT on managed devices, pointed at a resolver you operate or contract for that still enforces your protective DNS policy. On wireless, use WPA3-Personal at home and in small offices and 802.1X enterprise modes in organisations, with Protected Management Frames required and clients set to validate the RADIUS server's certificate. Keep guests on a separate network, with Enhanced Open where supported.

MACsec on LAN links, IPsec or WireGuard between sites

IEEE 802.1AE MACsec provides, in the IEEE's words, "connectionless user data confidentiality, data integrity, data origin authenticity" for Ethernet frames between two directly connected devices. Keys come from the MACsec Key Agreement protocol in IEEE 802.1X, which discovers mutually authenticated peers and elects a key server. MACsec encrypts per hop, so a tap on any protected cable sees only ciphertext, which makes it a good fit for links between buildings, leased fiber and uplinks through shared spaces. When traffic crosses networks you do not own, encrypt the whole path at the IP layer with IPsec or WireGuard instead.

Switch hardening, physical security and rogue AP monitoring

Turn on DHCP snooping and DAI, IPv6 first hop security, per port MAC limits and 802.1X on user facing ports, disable unused ports, and alert on any new mirror session. Lock and log comms rooms, label patch panels so an unexpected device stands out, and watch optical power on important fiber links for unexplained new loss. Since passive listening cannot be detected, invest where detection works: wireless intrusion detection sensors, often built into enterprise access points, can flag your network name broadcast from the wrong place, deauthentication floods and unknown devices bridged into the wired network.

Step by step: check your own setup

These commands check your own devices and services. Run them only against systems you own or administer. Replace example.com with your own domain.

1. Confirm your site negotiates TLS 1.3 and sends HSTS

# Which TLS version and cipher does your server negotiate?
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Does it refuse TLS 1.0? (expect a handshake failure)
openssl s_client -connect example.com:443 -servername example.com -tls1 </dev/null 2>&1 | grep -iE "alert|error|Protocol"

# Is HSTS set, and with what max-age?
curl -sI https://example.com | grep -i strict-transport-security

A TLS 1.3 line in the first output and a strict-transport-security header with a long max-age in the third are what you want. Some OpenSSL builds no longer include TLS 1.0 at all, in which case the second command reports that the option is unsupported, which is also fine.

2. See whether your domain publishes an ECH configuration

# HTTPS (type 65) DNS records can carry an "ech=" parameter
dig +short HTTPS example.com

If the output includes ech=, your hosting provider publishes an ECH configuration for that name. If not, ECH is not active for it, and the server name stays visible in the ClientHello.

3. Check that your devices use encrypted DNS

# Linux with systemd-resolved: look for "+DNSOverTLS" in the protocols line
resolvectl status

# macOS: list resolvers; encrypted DNS profiles appear in System Settings > Privacy & Security > Profiles or VPN & Filters
scutil --dns | head -40

# Windows 11: show resolvers with DNS over HTTPS templates configured
Get-DnsClientDohServerAddress

On Linux, +DNSOverTLS in the protocols line means DoT is enabled for that link. On Windows, a resolver listed with a DoH template and auto upgrade enabled is using DoH. Browsers can also run their own DoH; check the secure DNS setting in each browser you manage.

4. Check which Wi-Fi security mode you are actually connected with

# Linux with NetworkManager: SECURITY should read WPA3 or show 802.1X
nmcli -f ACTIVE,SSID,SECURITY dev wifi list | grep yes

# macOS: look at the Security field for the current network
system_profiler SPAirPortDataType | grep -A12 "Current Network Information" | grep -i security

# Windows: Authentication should read WPA3-Personal, WPA3-Enterprise or WPA2-Enterprise
netsh wlan show interfaces

If you see WPA2-Personal on a network you manage, plan a move to WPA3. If you see an open network, assume everything not protected by TLS or a VPN is readable by anyone nearby.

5. Require WPA3 and PMF on an access point you run

If your access point is built on hostapd, as many Linux based routers and appliances are, these settings require SAE and Protected Management Frames. Check your vendor's documentation for the equivalent options in its interface.

# hostapd.conf excerpt for a WPA3-Personal only network
wpa=2
wpa_key_mgmt=SAE
rsn_pairwise=CCMP
ieee80211w=2
sae_require_mfp=1

Setting ieee80211w=2 makes PMF required rather than optional. Leaving WPA2 in the key management list creates a transition mode network, which is useful during migration but allows older clients, and downgrade attempts, to use WPA2.

6. Sanity check your gateway's address on a LAN you manage

# Linux: neighbor table; your gateway's MAC should match the router's label or admin page
ip neigh show

# macOS and Windows
arp -a

If two different IP addresses on your LAN resolve to the same MAC address, and one of them is your gateway, investigate. It can be legitimate (some routers answer for several addresses) but it is also what ARP spoofing looks like from a victim's side. On managed networks, rely on DAI and switch logs rather than spot checks.

7. Confirm tunnels and link encryption are actually up

# WireGuard: shows peers and the time of the latest handshake
sudo wg show

# Linux MACsec interfaces and their secure channels
ip macsec show

# IPsec with strongSwan's swanctl: list established security associations
sudo swanctl list-sas

A WireGuard peer with no recent handshake, or a MACsec channel that is configured but not active, is a link you believe is encrypted that may not be.

Common mistakes

• Treating the internal network as trusted. Interception on a LAN, a leased fiber or a data center interconnect is well documented. Encrypt internal traffic the same way you encrypt traffic to the internet.
• Assuming a Wi-Fi password protects users from each other. On WPA2-Personal, anyone with the password who sees a handshake can derive another client's keys, as RFC 8110 explains. Use WPA3 or 802.1X.
• Calling Enhanced Open "secure Wi-Fi". It stops passive listeners but does not authenticate the access point. An evil twin with the same name still works against it.
• Leaving PMF optional. Optional PMF lets older clients connect without it, which keeps forged deauthentication available against them.
• Believing TLS hides everything. Server IPs, sizes, timing and, without ECH, the server name are visible. Plan for metadata exposure.
• Encrypting the web traffic but not DNS. Every site name still leaks through classic DNS on port 53.
• Using a personal VPN as a security blanket. It moves trust to the VPN operator. Use one when you trust that operator more than the local network, and keep TLS inside it.
• Forgetting the switch is a computer. An unpatched switch with a default management password gives an attacker port mirroring without touching a cable.
• Relying on SMS codes for important accounts. CISA warns that SMS is not encrypted and can be read by someone with access to a carrier's network.
• Never looking at the wiring closet. A tap is invisible on the network; only a physical check finds it.

FAQ

Can someone read my traffic if they plug into the same network?

On a modern switched network, plugging in does not by itself show other people's traffic. An attacker on the same segment can try ARP spoofing or MAC flooding to redirect or spill traffic to their port. Switch features such as Dynamic ARP Inspection, port security and 802.1X stop those techniques, and TLS keeps content unreadable even if they work.

Can fiber optic cables be tapped?

Yes. Optical splitters and bend taps can copy light from a fiber, and splitters are used lawfully every day for network monitoring. The difficulty is physical access to the cable, which is why fiber tapping is mostly a concern for well resourced attackers and for links you do not physically control. Encrypt those links with MACsec or IPsec.

Can people see what I do on public Wi-Fi?

On an open network with no password, anyone nearby can read any traffic not protected by TLS, a VPN or an encrypted app. With HTTPS they see which sites you connect to, but not the pages or what you type. On Enhanced Open or WPA3 networks, a passive listener cannot read the payload, but a fake access point with the same name remains a risk.

Does WPA3 stop someone with the Wi-Fi password from reading my traffic?

WPA3-Personal uses SAE, a key exchange between each device and the access point, rather than deriving keys directly from the shared password as WPA2-Personal does. A passive listener who knows the password therefore cannot simply compute your traffic keys from the handshake, which RFC 8110 describes as the core weakness of a shared PSK. Someone with the password can still join the network and attempt active attacks, so keep using TLS.

Does HTTPS hide which websites I visit?

Not completely. HTTPS hides the page, path and content. The server's IP address is visible, and without Encrypted Client Hello the site's name is sent in cleartext in the TLS handshake. DNS lookups also reveal names unless you use encrypted DNS. ECH, published as RFC 9849 in March 2026, hides the name when both the site and your browser support it.

Is UDP traffic easier to intercept than TCP?

Neither is easier to capture; both are copied the same way from the medium, and neither encrypts anything on its own. The difference is what runs on top. QUIC, which runs over UDP, encrypts its payload and most of its transport headers, while TLS over TCP leaves the TCP headers visible.

What is MACsec and do I need it?

MACsec (IEEE 802.1AE) encrypts and authenticates Ethernet frames between two directly connected devices, with keys agreed through IEEE 802.1X. You need it on links where someone could reach the cable or where you do not control the path, such as between buildings or on leased fiber. Inside a locked data center rack it is less critical if your application traffic already uses TLS.

Can my internet provider see my traffic?

Your provider can see every packet's addresses, sizes and timing. With HTTPS it cannot read content. With classic DNS it can see every name you look up, which encrypted DNS fixes. A VPN hides your traffic from the provider but shows it to the VPN operator instead.

How do I know if someone is sniffing my Wi-Fi?

You usually cannot. NIST SP 800-153 points out that passive interception sends nothing, so there is nothing to monitor electronically. What you can detect is active behaviour: rogue access points, deauthentication floods and unknown devices. That is why the defence for passive listening is encryption, and the defence for active attacks is monitoring.

Where Safeguard fits

Safeguard does not inspect network traffic, configure switches or access points, detect rogue devices or monitor radio spectrum, and none of the defences in this post depend on it. The honest connection is the software that implements those defences. TLS libraries, DNS resolvers and stub resolvers, VPN software, wpa_supplicant and hostapd, and the network stacks inside appliances and container images are mostly built from open source components, and each has its own security advisories over time. A TLS deployment is only as strong as the library version in the image that serves it. Safeguard scans repositories, container images and SBOM files for those components, matches them against vulnerability databases, applies reachability analysis, and shows which of your projects contain a given component and version. When a TLS or VPN library advisory lands, that is how you find which of your services and images carry the affected version. Our post on using SBOMs to find affected products fast walks through that workflow.

Fix it without waiting for upstream

Encryption only protects traffic if the code doing the encrypting is current: a TLS library, a DNS resolver or a VPN daemon pinned to an old version in a container image weakens every control in this post without anyone noticing. Those components ship in the images and dependencies you build, so the patch discipline below applies to them, while firmware in switches, access points and network cards still has to come from the equipment vendor.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency and image workflows, not network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. The same terminal scan can run against the container image that terminates TLS for your service or runs your internal DNS resolver, so the TLS and DNS library versions inside it are checked before it ships.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is a TLS, HTTP client or VPN library pinned in a manifest you own.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a particular TLS library version, and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 7258: Pervasive Monitoring Is an Attack (BCP 188, May 2014)
• RFC 7624: Confidentiality in the Face of Pervasive Surveillance, A Threat Model and Problem Statement (August 2015)
• RFC 2804: IETF Policy on Wiretapping (May 2000)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018)
• RFC 9849: TLS Encrypted Client Hello (March 2026)
• RFC 8744: Issues and Requirements for Server Name Identification (SNI) Encryption in TLS (July 2020)
• RFC 9000: QUIC, A UDP-Based Multiplexed and Secure Transport (May 2021)
• RFC 7858: DNS over Transport Layer Security (May 2016)
• RFC 8484: DNS Queries over HTTPS (October 2018)
• RFC 9250: DNS over Dedicated QUIC Connections (May 2022)
• RFC 6797: HTTP Strict Transport Security (November 2012)
• RFC 8110: Opportunistic Wireless Encryption (March 2017)
• RFC 5227: IPv4 Address Conflict Detection, security considerations on ARP
• RFC 3756: IPv6 Neighbor Discovery Trust Models and Threats (May 2004)
• RFC 4301: Security Architecture for the Internet Protocol (December 2005)
• IEEE 802.1: 802.1AE MAC Security (MACsec)
• IEEE 802.1: 802.1X Port-Based Network Access Control
• Wi-Fi Alliance: Security (WPA3, Wi-Fi Enhanced Open, Protected Management Frames)
• Wi-Fi Alliance: Wi-Fi Alliance introduces Wi-Fi CERTIFIED WPA3 security (25 June 2018)
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (February 2012)
• NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of TLS Implementations (August 2019)
• NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide (March 2026)
• CISA: Encrypted DNS Implementation Guidance (May 2024)
• CISA: Mobile Communications Best Practice Guidance (December 2024, updated November 2025)
• WireGuard project overview

Last reviewed: 23 October 2026. ECH support in browsers, servers and hosting providers is still rolling out; check your own stack's documentation for current status.