Rabby Wallet on Public WiFi: Network-Level Attacks and Why Your Browser Extension Is Still Vulnerable

A developer working from a coffee shop opens her laptop, connects to the café’s open WiFi, and launches her browser to check her Ethereum balance and approve a token swap through her Rabby Wallet extension. The interface loads normally. Her private keys remain encrypted on her device, as intended. Yet between her laptop and the blockchain, the network path is entirely unencrypted and monitored by the router, the ISP, anyone positioned on the local WiFi segment, or a malicious network appliance. A browser extension wallet stores cryptographic secrets locally—that is genuine security. But the route between the wallet and the services it contacts, the nodes it queries, and the dApps it communicates with is another problem entirely.

The security model of Rabby Wallet, like any non-custodial secure crypto wallet, depends on keeping private keys offline and encrypted. That part works. What it does not prevent is an attacker intercepting or modifying the requests that the wallet makes to web services, replacing the dApp interface that appears in the browser, hijacking DNS lookups, or injecting fake transaction confirmations. Public WiFi creates an environment where these attacks shift from theoretical to practical. Rabby’s local encryption does not defend against network-level compromise because the threats operate one layer higher in the stack.

Why local encryption does not protect network requests

Rabby Wallet’s architecture keeps private keys encrypted locally on the user’s device. That is correct and necessary. The encryption happens before any network interaction, and the decrypted key material never leaves the extension process. When a user approves a transaction, the signature is computed locally and only the signed transaction is broadcast. This design means that no compromise of a remote server, API service, or web-based dApp can directly steal the private key.

However, the wallet must still communicate with external services. It queries blockchain nodes to read account balances, nonce values, and transaction history. It fetches contract ABIs and metadata from services like Etherscan. It connects to DeFi protocols, NFT marketplaces, and price feeds. Each of these requests travels over the network unencrypted in terms of the payload—the URL, parameters, and response are visible to anyone observing the WiFi traffic. On a public network, that observer may be an attacker using a passive sniffer, a rogue access point, or a compromised router.

The distinction is between data in transit and data at rest. Rabby protects data at rest through encryption. The moment that data enters the network layer—DNS queries, HTTP requests, WebSocket connections—it becomes visible. A HTTPS connection protects the payload from modification, but it does not hide the fact that a request was made, the destination server, or metadata such as request size and timing. DNS lookups happen before HTTPS negotiation, making them especially vulnerable. An attacker who controls the network can redirect a lookup for api.example.com to a server under their control, presenting a fake interface that looks identical to the legitimate one.

Man-in-the-middle attacks against wallet interfaces and dApps

The most practical attack against a browser extension wallet user on public WiFi is not key theft but transaction manipulation. An attacker positioned on the network intercepts the connection between the browser and a DeFi dApp. Because the attacker can modify the page content before it reaches the user, they can change the token address in a swap form, alter the recipient address in a transfer, or present a transaction preview showing different numbers than the one that actually signs.

Rabby Wallet includes transaction preview functionality to help users inspect what they are signing before approval. This is valuable when the preview is accurate. But the preview itself is generated from data served by the same network path that an attacker can compromise. If an attacker intercepts the request to a smart contract reader service, they can provide false information about what a contract does, what fees will be charged, or what the actual recipient address is. The user sees what appears to be a safe transaction, signs it with their Rabby Wallet extension, and the actual signed transaction executes against an entirely different recipient or contract.

DNS hijacking makes this easier because the attacker does not need to be on the same WiFi segment. By compromising the router’s DNS settings or running a rogue access point that responds to DNS requests, they can redirect all traffic to a domain to a server they control. A user attempting to reach app.aave.com might be served a pixel-perfect replica running on 192.168.1.50. The browser displays HTTPS warnings if the certificate does not match, but not all users read warnings, and sophisticated attacks can use wildcard certificates or compromise certificate validation in specific ways.

DNS and HTTPS certificate vulnerabilities in public networks

DNS is a fundamental weakness in public WiFi security. When a user’s device joins a network and requests a domain name, the lookup is sent in plaintext to the network’s DNS server—often the router itself on open networks. An attacker running a packet sniffer can see every domain name the user visits and respond with a forged answer before the legitimate DNS server replies. This is called DNS spoofing, and it requires no special privileges on the network if the attacker is simply faster with their response.

HTTPS mitigates some of this risk by requiring a valid certificate for the domain. But certificate validation has practical gaps. A self-signed certificate, a certificate issued for a different domain, or a certificate signed by a trusted CA for a domain the attacker controls will trigger browser warnings. On a public network where users are distracted and in a hurry, many will click through these warnings without reading them. Additionally, older browsers or devices may have outdated certificate stores, and some users disable certificate validation entirely for convenience.

A more subtle attack exploits certificate transparency logs and domain registration. An attacker can register a domain that is visually similar to the legitimate one—for example, app-aave.com instead of app.aave.com—request a legitimate certificate for it, and then use DNS hijacking to redirect traffic to that lookalike domain. From a certificate perspective, everything is valid. The user’s browser sees a green lock icon. Rabby Wallet will function normally because it is simply displaying whatever page loaded in the browser tab, and that page is under the attacker’s control.

Transaction approval under network compromise

The critical moment is when the user approves a transaction through their Rabby Wallet extension. The extension displays a transaction preview and requests the user’s biometric authentication or password. Here, the security model does split appropriately: the user’s authentication and signing happen locally, and Rabby’s code validates the transaction against the wallet’s internal state. However, the transaction details that appear in the preview—the recipient address, the amount, the contract being called—come from the dApp interface that may have been compromised.

An attacker can prepare two versions of a transaction preview. The one displayed in the browser tab shows an innocuous swap: 100 USDC for 90 USDT. The actual transaction that the user signs sends the wallet’s entire balance to an address the attacker controls. The extension does not typically display the full transaction bytecode; it interprets it and presents a human-readable summary. If that interpretation is fed false data by a compromised dApp, the user approves a signature for something entirely different from what they believe.

The defense is to verify transaction details outside the potentially compromised browser. On a public network, this might mean checking the contract address and recipient against a known-safe source—a separate device, a hardware wallet’s display, or a blockchain explorer accessed through a secure connection. Rabby Wallet’s hardware wallet compatibility with Ledger and Trezor can add a layer of defense here: the hardware wallet performs its own transaction validation and displays the details on its own screen, which is isolated from the compromised network.

Practical hardening for remote workers and travelers

The first defense is to avoid storing significant balances in a browser extension wallet when traveling or working remotely on untrusted networks. A hardware wallet stored in a safe location, used only when necessary, or an air-gapped signing device reduces exposure dramatically. For unavoidable remote wallet access, a VPN is foundational but insufficient. A quality commercial VPN encrypts traffic between the user’s device and the VPN server, making it invisible to the local network. However, the VPN provider itself can see the traffic, and the security depends entirely on the provider’s integrity, logging practices, and resistance to subpoena or government coercion.

Using a VPN masks the content from the local network and router, but it does not solve DNS hijacking or compromised dApps. To address DNS specifically, a user can configure their device to use a trusted DNS resolver—for example, Cloudflare’s 1.1.1.3 for malware filtering, or Quad9 for additional blocking. This prevents the router from intercepting DNS queries. However, a sophisticated attacker positioned on the same WiFi can still perform SSL stripping if the application does not enforce HTTPS strictly, or can use ARP spoofing to intercept even encrypted traffic by positioning themselves as the network gateway.

A more robust approach combines multiple layers. First, use a VPN or a separate secure network such as a personal mobile hotspot rather than the café WiFi. Second, verify any critical addresses against a known-safe source before entering them into a transaction. Third, use a hardware wallet for approvals of high-value transactions. Fourth, limit the balance stored in the browser extension to an amount that represents acceptable loss. Fifth, disable unnecessary browser extensions and regularly audit permissions. If the browser extension itself is compromised or if malicious JavaScript is injected into a page you trust, no amount of network hardening will help.

Biometric authentication in Rabby Wallet protects against casual access to an unlocked device, but it does not protect against network-level attacks or compromise of the browser process. The security model assumes that the device itself is trusted and that the network or dApp services may be hostile. On public WiFi, assume that the network is hostile. On any shared computer, assume that the device is not trustworthy. The proper environment for using a non-custodial Web3 extension with significant holdings is a personal device on a private network, connected through a VPN if remote access is necessary.

Regular updates and certificate pinning as incomplete solutions

Rabby Wallet receives regular security updates distributed via the official site, and keeping the extension current is essential. These updates address newly discovered vulnerabilities in the extension code itself. However, updates cannot prevent an attacker from compromising a third-party service that the wallet queries, nor can they prevent DNS hijacking or rogue access points. Updates are a necessary but not sufficient control.

Certificate pinning—hardcoding the expected certificate for critical services directly into the extension—can prevent some MITM attacks. If Rabby’s code includes a pinned certificate for Etherscan or a node service, an attacker cannot present a forged certificate and fool the extension. However, pinning creates a fragility: if the legitimate service rotates its certificate and the extension is not updated promptly, users will lose access. Certificate pinning also only works for services that the extension directly connects to, not for dApps loaded in the browser tab.

A more realistic posture is to assume that some third-party services will be compromised or intercepted. The defense is compartmentalization and verification. Use multiple data sources for critical information rather than relying on a single service. Check contract addresses against multiple block explorers. Verify that the transaction you see in the preview matches the one displayed by your hardware wallet. Rabby Wallet’s design keeps private keys safe; your responsibility is to keep the information that feeds those keys honest.

Why travelers should reconsider hot wallet exposure

For a user traveling internationally or working from multiple locations, a browser extension wallet like Rabby represents a constant availability of funds under uncertain network conditions. The convenience of being able to swap tokens or check balances from any device comes with the risk of network-level compromise. An attacker with access to a border gateway, a compromised hotel WiFi, or a state-level position on international traffic can operate with few constraints. They can monitor DNS queries across thousands of users, redirect traffic selectively, and run multiple phishing operations in parallel.

A more conservative model uses Rabby as a convenience wallet for small amounts and frequent transactions on trusted networks only, while keeping larger holdings in cold storage or hardware wallets. When traveling, this might mean funding the Rabby Wallet from a hardware wallet stored in a safe location before departure, spending from Rabby as needed, and then moving remaining funds back to cold storage. This requires more steps and more transactions—which increase fees—but it dramatically reduces the window of exposure.

Another option is to defer all significant transactions until returning to a known-good network. Blockchain transactions do not expire, and there is no penalty for waiting. A user who sees an attractive DeFi opportunity while traveling via public WiFi can make a note, return home, verify the terms on a secure network, and execute the transaction then. The discipline to not act immediately in an uncontrolled environment is often the single best security decision. You can learn more about Rabby’s security architecture and recommendations from the official documentation, but no extension can make a public WiFi network trustworthy.