DNS attacks and on-path attacks are among the most significant threats to software distribution integrity. Both involve an attacker inserting themselves between a user and a legitimate resource, either by manipulating how domain names resolve or by intercepting network traffic directly. Understanding how these attacks work explains why code signing and TLS certificates exist as complementary defenses rather than redundant ones.
This guide explains the mechanics of DNS cache poisoning, DNS hijacking, and on-path attacks, examines how each threatens software download channels, and describes exactly what protection code signing provides against these threats and where its limits are.
How DNS Works (The Brief Version)
When a user types yourcompany.com into a browser or your update client looks up the download server’s address, the operating system sends a DNS query to a resolver (typically the ISP’s DNS server or a configured public resolver like 8.8.8.8). The resolver consults authoritative DNS servers for the domain and returns the IP address. The application then connects to that IP address.
The DNS system was designed in the early 1980s with no built-in authentication. DNS responses are plain UDP packets with no cryptographic verification. A resolver that receives a DNS response has no way to confirm that the response came from the legitimate authoritative server rather than an attacker. This architectural limitation is the root cause of DNS attack vulnerabilities.
DNS Cache Poisoning: Corrupting the Resolver’s Memory
DNS resolvers cache the answers they receive to avoid making the same query repeatedly. Cache poisoning exploits this by injecting false records into a resolver’s cache. Once poisoned, the resolver serves the attacker’s false IP address to every client that queries it until the cached record expires.
The classic DNS cache poisoning method, described by Dan Kaminsky in 2008, exploits predictable transaction IDs and source ports in DNS queries. When a resolver sends a query to an authoritative server, an attacker who can send many forged responses quickly may cause the resolver to accept a false response before the legitimate one arrives. Once the false record is cached, every user of that resolver asking for the poisoned domain receives the attacker’s IP address.
A successful DNS cache poisoning attack against a domain’s download server means that users attempting to download software receive the content from the attacker’s server. The URL in their browser still shows your domain. The TLS certificate presented by the attacker’s server would need to match your domain (requiring a fraudulently issued certificate) for HTTPS to pass without warnings. Without a valid certificate for your domain, the browser shows a TLS error before any software is downloaded.
DNS cache poisoning against an HTTPS download URL requires two simultaneous attacks to succeed silently: the DNS attack (to redirect to the attacker’s server) and a TLS attack (to present a valid certificate for the domain). The combination is difficult but not impossible: a compromised CA, a Certificate Transparency log miss, or HSTS bypass could potentially enable it. This is why the defense-in-depth model matters: TLS protects the channel, but code signing provides a final verification that the software itself is authentic even if the channel was compromised.
DNS Hijacking: Controlling the Authoritative Source
DNS hijacking is distinct from cache poisoning in that the attacker gains control over the actual DNS records for a domain rather than poisoning a resolver’s cache. This typically happens through:
- Registrar account compromise: An attacker obtains credentials for the domain registrar account (through phishing, credential stuffing, or password reuse) and modifies the domain’s DNS records directly. The attacker changes the A record for your download server to point to their infrastructure.
- DNS provider compromise: The domain’s DNS hosting provider is breached and records are modified.
- BGP route hijacking: At a network routing level, an attacker announces false BGP routes causing internet traffic to be misdirected to attacker-controlled infrastructure. This does not require DNS access but achieves a similar redirecting effect on traffic.
DNS hijacking is more durable than cache poisoning because the false records come from the authoritative source itself. Resolvers querying the authoritative DNS server receive the attacker’s IP address as the legitimate answer. The attack persists until the domain owner detects and reverses the modification.
High-profile DNS hijacking attacks against software vendors and update servers have occurred. The Sea Turtle campaign (2018-2019) targeted registrars and DNS providers across multiple countries to redirect traffic from government agencies and security companies. The attack was effective specifically because DNS hijacking is invisible to end users: the URL appears correct and the traffic goes where the domain resolves.
On-Path Attacks: Intercepting Traffic Directly
An on-path attacker (previously called a man-in-the-middle attacker) is one positioned on the network path between the user and the server such that traffic passes through the attacker’s systems. Unlike DNS attacks which redirect before connection, an on-path attacker intercepts traffic after the DNS resolution has succeeded correctly.
On-path positions can be achieved through:
- Network infrastructure control: An attacker who controls a router, switch, or network device on the path between user and server can intercept all traffic passing through it. Corporate networks, ISPs, and cloud providers are all positioned on-path relative to their customers’ traffic.
- ARP poisoning: On local networks, ARP cache poisoning can redirect traffic between two hosts through the attacker’s machine, enabling interception of LAN traffic.
- Rogue access points: A malicious WiFi access point positions the attacker on-path for all traffic from connected users. Public WiFi environments are particularly susceptible to this.
- ISP or state-level interception: National-level network operators can be compelled or coerced to intercept traffic. Deep packet inspection at scale enables traffic modification for targeted users.
An on-path attacker observing unencrypted HTTP traffic can modify the response in transit. If a user downloads software over HTTP, the on-path attacker can replace the downloaded binary with a malicious version before it reaches the user. The user’s browser shows the correct URL and the file arrives as if from the legitimate server.
What TLS Protects Against (And Where It Stops)
TLS (the protocol behind HTTPS) defends against on-path attacks on the connection itself. When a user connects to a TLS-protected download URL, the server presents an SSL certificate. The browser verifies the certificate chains to a trusted CA and that the domain name matches. An on-path attacker intercepting TLS traffic cannot read or modify it without either presenting a valid certificate for the domain (which requires either a fraudulently issued certificate or a compromised CA) or breaking TLS’s cryptographic guarantees.
TLS is an effective defense against passive on-path interception. But TLS alone does not verify what is delivered once the connection is established. If an attacker compromises the server itself (rather than intercepting traffic), or if a fraudulent certificate is obtained enabling active interception, TLS cannot distinguish the attacker’s content from legitimate content. What the server sends is what the client receives, encrypted and authenticated to the server, but the server’s content could itself be compromised.
Code Signing: What It Protects When TLS Cannot
Code signing and TLS protect different things and operate at different layers. TLS protects the channel: it ensures that data in transit between client and server is not readable or modifiable by an on-path attacker. Code signing protects the artifact: it ensures that the software file itself was produced by a specific publisher and has not been modified since signing, regardless of how the file was obtained or through what channel.
This distinction matters when considering what an attacker achieves with different attack vectors:
- On-path attack against HTTP download: An on-path attacker can replace the downloaded file entirely. If the replaced file is run, it executes the attacker’s code. Code signing defeats this: if the attacker’s replacement file is not signed with the legitimate publisher’s certificate, Windows shows ‘Unknown Publisher’ or a signature error. The attacker cannot produce a valid signature without access to the publisher’s private key.
- DNS cache poisoning to attacker’s server: The user’s connection goes to the attacker’s server. If the attacker’s server serves malicious software, code signing defeats the same way: the malicious file lacks the legitimate publisher’s signature.
- Server compromise: If the legitimate download server itself is compromised and the attacker replaces files on the server, TLS continues to work (the traffic is encrypted and authenticated to the server) but delivers attacker content. Code signing defeats this: the replaced files are not signed with the legitimate publisher’s private key.
| Attack scenario | TLS provides protection? | Code signing provides protection? | Combined outcome |
| On-path attacker modifies HTTP download | No: HTTP has no encryption | Yes: modified file lacks valid signature | Code signing catches the tampering despite no TLS |
| On-path attacker intercepts HTTPS with valid cert | No: if attacker has valid cert, TLS passes | Yes: attacker’s file still lacks legitimate signature | Code signing adds a second verification layer |
| DNS cache poisoning redirects to attacker server | No: user connects to attacker’s IP | Yes: attacker’s server cannot produce legitimate-signed files | Code signing defeats the end result regardless of routing |
| Server compromise (files replaced on legitimate server) | No: TLS authenticates the server, not the content | Yes: replaced files are not signed by legitimate publisher | Code signing catches server-side compromise TLS cannot see |
| Complete PKI compromise (CA issues fraudulent cert) | No: TLS accepts the fraudulent cert | Yes: code signing uses independent PKI; attacker still needs signing key | Code signing’s separate key requirement remains a barrier |
The table above illustrates why code signing and TLS are described as complementary rather than redundant. They address overlapping but distinct parts of the attack surface. An attacker who can compromise a CA to obtain a fraudulent TLS certificate and simultaneously compromise the developer’s code signing private key has overcome both defenses. This combination requires a much higher level of attacker capability than defeating either defense alone.
What Code Signing Cannot Defend Against
Understanding the limits of code signing protection is as important as understanding what it provides.
- Private key compromise: If an attacker obtains the legitimate publisher’s private key (through a breach of the developer’s systems, theft of a hardware token, or exploitation of a cloud HSM service), they can sign malicious software with the legitimate certificate. The resulting signature is cryptographically valid. Code signing provides no protection in this scenario; it becomes the attack vector.
- Social engineering around warnings: A user who clicks through ‘Unknown Publisher’ warnings, enables test signing mode, or disables UAC prompts defeats code signing’s user-facing protections. Technical defenses depend on users responding appropriately to security indicators.
- Attacker already trusted by the end-user system: If an attacker installs their certificate in the victim’s Trusted Publishers or Trusted Root store, they can sign files that Windows treats as trusted. This requires prior system access but enables ongoing trust afterward.
- Supply chain compromise of build tooling: SolarWinds and similar attacks compromise the legitimate build process itself. Malicious code is inserted before signing. The resulting binary is legitimately signed by the real publisher because the publisher signs it. Code signing verifies the output of the build process; it does not verify the integrity of the build process itself.
DNSSEC: Cryptographic Protection for DNS
DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records. An authoritative DNS server signs its records with a private key. Resolvers that validate DNSSEC can verify these signatures against the public key and detect forged or modified DNS responses.
DNSSEC adoption has been gradual. Many domains and many resolvers do not support DNSSEC. When DNSSEC is in place for a domain and a validating resolver is used, DNS cache poisoning attacks against that domain are defeated: the resolver detects that the response’s signature does not match and rejects the false record.
DNSSEC does not protect against all DNS attacks. DNS hijacking at the registrar level (compromising the domain owner’s registrar account) allows the attacker to replace DNSSEC signing keys as well as DNS records. DNSSEC protects the integrity of records in transit, not the authorization of who can modify them at the source.
For software publishers, enabling DNSSEC on your download domains provides a defense-in-depth layer against DNS cache poisoning targeting your users’ resolvers. Combined with HSTS (HTTP Strict Transport Security) and certificate pinning for update clients, DNSSEC contributes to a layered distribution security posture.
Frequently Asked Questions
What is the difference between a DNS attack and an on-path attack?
A DNS attack manipulates how domain names resolve to IP addresses, redirecting users to the attacker’s infrastructure before any connection is established. The redirection happens at the DNS layer. An on-path attack intercepts traffic after DNS resolution, positioning the attacker between the user and the legitimate server. Both attacks can achieve similar outcomes (delivering malicious software to a user who believes they are downloading from a legitimate source) but through different technical mechanisms and at different points in the connection process.
If a download is served over HTTPS, can an on-path attacker still replace the file?
Not without either presenting a valid TLS certificate for the domain (which requires a fraudulently issued certificate or a compromised CA) or compromising the server itself. A passive on-path attacker who cannot produce a valid certificate will see HTTPS connections fail with certificate errors from the user’s browser. An active attacker with a fraudulent certificate can intercept and modify HTTPS traffic silently. This is why code signing provides value even when HTTPS is in use: the attacker’s modified file still lacks the legitimate publisher’s Authenticode signature.
How does code signing protect against supply chain attacks?
Code signing protects against the distribution layer of supply chain attacks: an attacker who compromises a distribution server or a download channel cannot substitute a malicious file for the legitimate signed binary without the modified file being flagged as unsigned or with an invalid signature. Code signing does not protect against attacks at the build layer, where malicious code is introduced before signing. Build integrity requires separate controls: reproducible builds, binary provenance tools, and supply chain security practices such as SLSA (Supply Chain Levels for Software Artifacts).
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.