The Tor relay incident shows why an SSH identity warning deserves a stop

An unexpected SSH host-key warning led a researcher to identify 333 Tor exit relays involved in an interception campaign. Kaba’s October 20 investigation describes traffic being diverted through attacker-controlled servers during an episode earlier this month. The affected exits were subsequently removed from service, but the warning that exposed the attack remains an everyday decision for anyone administering a remote machine.

The central distinction is between hiding a connection’s origin and authenticating its destination. Tor changes the route traffic follows. It does not make an unfamiliar server key trustworthy, and it does not turn an unencrypted application protocol into end-to-end encrypted communication.

The warning was useful precisely because it interrupted work

SSH remembers a server’s identity so that a later connection can be checked against it. A changed host key can have a legitimate explanation, such as an administrator rebuilding a machine. It can also mean the connection has arrived somewhere else. The client cannot settle that question merely by observing that the user wants to continue.

Kaba reports receiving a different fingerprint after the connection was redirected. The subsequent investigation checked both the key presented to the client and where the connection appeared to come from at the intended server. That second observation mattered: not every affected route presented the same visible interception behavior.

The defensible response to a surprise is therefore to verify the new identity through an independent, trusted channel. Automatically discarding the remembered key removes the very comparison that made the anomaly visible. A convenient reconnection is not evidence that the discrepancy was harmless.

A relay network still runs on ordinary servers

The affected operators’ account describes a reused password on a management server and the presence of the Ebury backdoor. Its detailed examination covers two servers; the authors explicitly leave open how the entire group of affected hosts was reached. That boundary should survive any summary of the incident.

The management machine was particularly consequential because it connected administration, automation and backups. Credentials and access that made routine operations convenient also created routes for an intruder. Encrypting a backup offers less protection when its decryption password is the same secret already available on the compromised host.

The report also explains why a clean package checksum was insufficient reassurance in this case. The malicious component existed alongside an unchanged packaged library, with loading behavior altered around it. Verifying that a package’s files have not changed answers a narrower question than whether the running process has loaded only trustworthy code.

Encryption has to reach the intended endpoint

The researchers describe changes to relay policies affecting mail traffic as well as SSH interception. Blocking encrypted mail paths while leaving plaintext alternatives available creates a dangerous opportunity if an application falls back. It does not establish that every affected user’s email was read, nor that properly authenticated encrypted web traffic was decrypted.

That distinction avoids two bad conclusions: treating the incident as proof that all Tor communication was exposed, or assuming a privacy network can compensate for any application-level decision. The network path, the application’s encryption and the identity of its endpoint remain separate protections.

The operators retired the affected infrastructure, and Kaba credits the network-health response with removing the identified exits. Attribution and the complete initial-access chain remain unresolved. For a user facing a changed SSH fingerprint, however, the practical lesson does not depend on naming the attacker. The interruption may be the part of the connection that is working correctly.