Selective Denial of Service (DoS) Attacks: Remailer Vulnerabilities

(Note: this article came from remailer-operators/cypherpunks. The author is RProcess and this article is reprinted with permission.) rprocess@nym.alias.net

The following is a (somewhat long) discussion of what I consider to be some of the primary vulnerabilities in the current Cypherpunk/Mixmaster anonymous remailer system, and how I suspect some of these vulnerabilities are being quietly exploited.

It is not my intention to undermine confidence in the current system, which does offer substantial security and usefulness, but to discuss potential and probable threats with the goal of long-term improvement.

To date I have written three remailer clients (Potato, JBN 1 and 2) and a Windows remailer (Reliable), and in attempting to test the features thoroughly over several years time, have observed various problematic aspects of the remailer system, and have attempted to analyze anomalies very carefully. I am sharing these observations now because I am fairly confident that if they are not accurate, they are at least plausible fiction, and thus worthy of consideration.

Contents:

• WHAT I HAVE OBSERVED
• SELECTIVE DOS
• PLAUSIBILITY
• THE HOLE
• WHAT I HAVE NOT OBSERVED
• OTHER ATTACKS
• WHY BE CONCERNED?
• WHAT CAN BE DONE
• THE NEXT GENERATION
• IN CLOSING

WHAT I HAVE OBSERVED

Briefly, I have observed the same thing that many remailer users have complained about for some time - lost mail. The possible difference is that I have investigated it a little more deliberately than most users would care to do. Some mail sent through remailers vanishes. This has previously been explained as unreliable software, hardware, networking, etc. However I have found these explanations to be insufficient to explain my observations.

One of the goals of writing Potato (and likewise JBN) was to provide a remailer client that would be very accurate and dependable, thus providing a means to produce consistent and dependably formatted mail. By allowing users to save templates of message constructions, it removes a lot of human error. It also provides an artificial memory by which a user can verify whether or not a missing message was constructed properly.

Likewise, Reliable (as the name implies) was designed to do everything possible to eliminate disappearing messages. Reliable is very reluctant to discard messages, and has several tiers of message disposal, with the ability to requeue messages which are unprocessed due to misconfiguration or other questionable problems. In addition, the Freedom and Mixmaster remailers have undergone a lot of work by Johannes Kroeger and Ulf Moller which I believe has made them much more dependable (and secure) than remailers operating some years ago.

As a result of these improvements we have clients and servers which run consistently and with a large degree of reliability. So why is it so very difficult to generate a dependable and secure reply-block?

Some of my observations:

• Some mail vanishes, particularly if unique (not sent through a previously established encrypted reply-block).
  
• Mail which is securely encrypted is more likely to vanish or be delayed than are simple messages.
  
• Mail which is well-chained is far more likely to be lost, even allowing for increased probability of serial failure and other causes, even when all remailers in the chain test ok.
  
• Ping messages are more reliable than real mail. The new version 2 stats reveal that most remailers are very consistent and reliable in processing pings, and true network and server down time is very obvious and quite rare. Yet actual use of the remailers in chains paints a very different picture than these stats.
  
• Established reply-blocks may work flawlessly, while a newly created reply-block with the same remailers will be delayed or lost.
  
• New reply-block chains are delayed for the first several uses.
  
• There is a correspondence between nym accounts and new reply-block unreliability. (ie a new reply-block for xxx@nym.alias.net will be consistently more unreliable than the same or similar reply-block for yyy@nym.alias.net)
  
• Remailer operators complain of their stats being low despite their remailer functioning normally.
  
• Conduction of some news messages between servers is impeded beyond expectations.

Isolated incidents can be dismissed as coincidence, due to traffic levels, and other variations, but over time the trends become very clear and disturbing, the reasons ever diminishing. I think most remailer and nym users are well acquainted with this behavior, to the point where they take it for granted, and I think some of those who work in providing remailer services or software are unaware of the problem simply because they don't actually use the services extensively.

I think one of three basic possibilities exist for an explanation of the unreliability. One, unreliable remailer software (servers discarding the messages despite their delivery and clients generating malformatted messages). Two, an unreliable network which is not delivering the messages. Three, a third influence, deliberate or otherwise, which is preventing their delivery or processing.

I have satisfied my own questions regarding the first. While I admit that software problems do occur, they are not widespread and subtle to the extent which would cause this much lost mail and unpredictability, and predictable loss without discernable and reproducible cause.

Regarding the second possibility, internet reliability has increased. How often does plain email disappear into a void? Not often. Nor would this explain the 'intelligent' nature of the losses I have observed.

Despite trying to resist the paranoid alternative, I have come to conclude that the third alternative is the case - that something or someone is interfering between the users and remailers, and between remailers, engaging in a very subtle and selective DoS attack.

SELECTIVE DOS

DoS refers to Denial of Service. One kind of attack on encrypted or secure communication involves sabotaging the communication, or denying the service. An example is a mail bomb sent to a remailer. While recovering from the mail bomb the remailer is unable to process messages, and thus users are denied service, are unable to communicate.

By selective denial of service I refer to the ability to inhibit or stop some kinds or types of messages while allowing others. If done carefully, and perhaps in conjunction with compromised keys, this can be used to inhibit the use of some kinds of services while promoting the use of others. An example:

User X attempts to create a nym account using remailers A and B. It doesn't work. He recreates his nym account using remailers A and C. This works so he uses it. Thus he has chosen remailer C and avoided remailer B. If the attacker runs remailers A and C, or has the keys for these remailers, but is unable to compromise B, he can make it more likely that users will use A and C by sabotaging B's messages. He may do this by running remailer A and refusing certain kinds of messages chained to B, or he may do this externally by interrupting the connections to B.

User Y attempts to create a very secure reply-block using advanced anti- analysis features (perhaps long latency, random hops, superior encryption, etc). His reply-block fails outright or is so unreliable that he decides to change it. He forgoes some of his advanced features for a more reliable (yet less secure) reply-block. Thus the attacker has induced the user to use less secure features, or perhaps has discouraged the use of remailers completely.

User Z attempts to create a reply-block, or send a message. Again and again he has failures so he sends himself test messages using similar remailers and features, or if he is inexperienced he may mail his own account directly. By inhibiting the success of his mail, the attacker has made it more likely that the user will expose himself through testing, repetition, and security oversights. How many new users are creating new reply-blocks at any given time? Not that many, especially given a thorough statistical analysis.

Another example: It is somewhat possible to tell how long a reply-block is by examining the size of the encrypted reply-block. Thus the attacker kills some or all messages with longer chains, reducing their use.

Thus through selective denial of service, the following can be accomplished:

• Choice of remailers influenced
• Choice of features influenced
• Cause testing and repetition to be required
• Longer chains inhibited
• General dissuasion of remailer use due to unpredictability

PLAUSIBILITY

How plausible is the scenario that someone is doing this?

Cutting to the chase, I think the most plausible organizations responsible for such an attack would be the usual suspects - NSA, CIA, and other military and intelligence organizations. They have the means and the motives to make such an attack worth their while. Given operations like Echelon (NSA's widespread interception of electronic communication in Europe), and other intelligence networks such as the CIA's meddlesome habits, it is reasonable to assume they are doing *something* with regard to remailers. Remailers potentially allow organizations to communicate in an untraceable fashion worldwide. A lot of intelligence and counterintelligence is based on interrupting untraceable communication. So it is reasonable to assume they are doing something.

What is it likely that they are doing? Given their habits, it is most likely they would do something as subtle as possible. They would prefer their intrusion to be undetected and unverifiable, with no traces left behind. They would prefer to leave the illusion that the system has not been compromised.

THE HOLE

The reliability hole in the remailer system provides a way, perhaps the best way, to accomplish these goals. A lost message only provides evidence by its absence, so there is no positive evidence of a third party at work. It provides a way to influence remailer use, and it uses other genuine remailer problems as cover. It also uses the difficulty of producing reliable remailer messages manually as cover, although this has become less of an issue with reliable clients.

As long as remailers have been around, unreliability has been a problem. Further, as remailers became more reliable, chaining reliability began showing inexplicable deficiencies. We take stats lists for granted, but why do we need such an elaborate fix? Why have software and network problems remained for so long? Or have they? After extensive analysis, I see very little evidence of software or network problems causing these losses, and the only alternative explanation remaining is deliberate interference.

I think remailer users and developers have become complacent about the reliability problem, accepting it, and thus accepting a large vulnerability in the system. But is it understandable, because it is a very difficult problem to pinpoint and document.

WHAT I HAVE NOT OBSERVED

What are the alternatives to a selective DoS attack?

I will not say these things don't exist or haven't been done, but I have not observed the following directly or indirectly.

• A Non-Selective DoS - A remailer or group of remailers being completely switched off or blocked.
  
• False Keys - Distribution of false keys and false signatures could be used in a man-in-the-middle or other attack, but again this leaves possible evidence that someone has compromised the system or attempted to do so.
  
• Hacking Attacks - There is little evidence to indicate a coordinated hacking attack.
  
• Trojan Viruses - Planting software which can steal keys or otherwise damage the system is plausible. I have read the usual bits which indicate this does go on in software, but I have not witnessed this problem directly or related to remailers. Again note that this leaves tracks. I think the more plausible method in encryption and security products would be for weaknesses to be introduced which could later be claimed to be programmer or design errors.

OTHER ATTACKS

Of course there continue to be other vulnerabilities. Anyone can run a remailer, and it stands to reason that one method of intercepting some mail, and selectively deleting some mail, would be for the attacker to run one or more remailers.

There is also the threat of key theft. Based on what I have observed, I consider it a very strong possibility that at least some keys are available to those performing what I suspect is a selective DoS. Given nym.alias.net's location at MIT (home of half of the DOD), a college computer with only reasonable security, and given the fact that the key has not been changed for years, I find it reasonable to suppose that the key has been stolen.

There remains the possibility of keys or messages being cracked. This takes time and could explain some of the curious delay trends observed by myself and others. However one has to suppose that some of the encryption schemes are somewhat secure or there would be no incentive to perform a selective DoS.

I find it plausible that intelligence agencies would construct a campaign to report and generate abuses, causing remailers to be shut down by ISPs, etc., and to generate mail bombs and other attacks when suited to their purposes. This is in general keeping with the history of their indirect involvement.

WHY BE CONCERNED?

One argument is that unless you are a spy or a terrorist, it may not matter much that the intelligence agencies read your mail or trace your identity. They don't involve themselves much with law enforcement, preferring to break the laws themselves, except when it suits their purposes.

However these people are unlawfully and often unethically exerting an influence, and most users concerned with privacy and free expression issues are concerned by this kind of interference.

Further, the anonymous remailer system has grown from being vulnerable to the type of attack used against anon.penet.fi, to using nym-servers where even the operator does not know the identity of account owners. One hopes that other vulnerabilities will be addressed as the need for privacy and free expression grows.

Finally, this is of concern to all remailer users as it makes the remailer system devilish to use.

I realize that contemplation of conspiracies are awkward, but in the case of remailers I think it is safe to assume intelligence agencies are involved in some way. The only remaining question is how.

WHAT CAN BE DONE

I would like to enumerate several short-term and long-term ideas for how the remailer system can be improved and made less vulnerable to selective DoS and other attacks.

• RELIABILITY
  Unreliable software and network connectivity provides a cover for selective DoS and other attacks. Remailer and client programmers, and remailer operators, need to do everything possible to improve the reliability of their systems and reduce lost mail, and to insure their connectivity to other remailers. The correct keys need to be used by remailers which increasingly depend on repgp and remix. It is my opinion that anti-SPAM features in some remailers have grown out of control and contribute to message loss, so these techniques must be applied carefully and only to a necessary extent. Remailers need to provide clear feedback to operators on why mail is being discarded, and operators need to pay careful attention to this information. Most of all, those involved in providing remailer services (programmers, operators, etc.) need to become less complacent about unreliability. It is a significant problem and security threat.
  
• KEYS
  The habit of keeping the same remailer keys indefinitely represents a significant security threat. Keys should be replaced and destroyed regularly, especially for remailers located in institutions and other areas where people come and go. Larger keys should also be used when possible.
  
• REMIX AT NYM-SERVERS
  The remailers located at nym-servers need to support Remix-To. Too much information about reply-block size and count is leaked between the nym-server's Cypherpunk and the first remailer.
  

THE NEXT GENERATION

A few thoughts on what next generation remailers should address.

• The idea of sending messages individually between remailers (and even from/to individuals?) should be discarded. Message packets should be made smaller (1k perhaps, interleaved) or larger (2-10 meg digests) and constructed in such a way that it is impossible to remove one packet or message without detection and correction. Multiple messages to a final destination might be sent in digests.
• An automatic system for detecting and replacing, possibly rerouting, lost packets should be implemented.
• More random data (continuous if feasible) should be introduced to cover the number and size of messages between locations.
• The assumption that an attacker has a remailer's private key or is able to decrypt its messages should be used in building a model which, while not preventing some eavesdropping in such a circumstance, prevents selective DoS.
• Email as the preferred method of transfer between remailers should be questioned. Although it provides for greater cross-platform interoperability, an encrypted direct connection between remailers, with error detection and correction is needed.
• Remailer clients need the (optional) ability to connect to the remailers directly, without going through SMTP and other servers, and need to receive immediate feedback that the remailer received the data.
• An automated and secure method for distributing and changing remailer keys regularly, and a system for updating client configuration (based on remailers' supported features) is needed.
• Remailers need to be less dependent on the DNS system to prevent hijacking and extended downtime (such as when nym.alias.net lost its domain for several months)

IN CLOSING

I do not intend to imply that all lost mail is due to involvement of a third party. Especially if you are new to remailers, realize that there are many mistakes which will legitimately cause remailers to discard messages. By design they are quite unforgiving in this regard, and users should not jump to conclusions.

I also wish to add that I still consider anonymous remailers to be one of the few methods on the net for achieving genuinely high levels of strong anonymity and security. It is exactly because of this that I consider it plausible that they are the target of such a subtle and resource-intensive attack.

Please send any questions or comments to webmaster@eff.org