Uggh another post which turned out hugely long... I cc'd to remailer ops due to remailer operator relevance. Steve Schear <azur@netcom.com> writes:
On Wed, 6 Aug 1997, Adam Back wrote: I propose that an exit remailer is replaceable, that is another remailer can instantly step into it's place and take traffic. The way to do this is to have a special automated reporting mechanism for exitman remailers. An easy way to do it is to have the exitman remailers send mail to a given mailing list. Other remailers which wish to use exitman remailers just subscribe to the chosen mailing list. We just need a remailer command indicating the creation of a new exitman remailer. I guess the exitman remailer just sends one message per day, or whatever, and if it stops, you write it off.
A possible problem is the motivation of those setting up decoys. If they're doing it to help thwart remailer abuse, fine. But what if their intent is to thwart remailers? Couldn't these dissidents set up black-hole remailers which are simply information sinks?
Good point, they could indeed. There is another related problem which is a real thorny one: Being exit only, the attacker will by definition know the email address the messages it forwards are being sent to. The attacker is trying to maximise his ability to disrupt, so he will be trying extra hard to conceal from remailer operators and their community that he is disrupting. Clearly the clever attacker in this situation, trying to disrupt the exitman-using middleman remailers reliability will let through anything going to a public forum, or to an email address he suspects is anything to do with Raph's pinging service. (Eg any address on the cypherpunks list or remailer-ops list as possible collaborators in the remailer reliability pinging). If the attacker is a Fed or spook or whatever, he will have good resources and ability to correlate destination email addresses to cypherpunks list members. Eg you get an account somewhere, they can find out by looking at your credit card logs, or whatever. Counter-measures? 1) Counter measure #1 A sop I can offer to this difficulty of detecting denial of service attacks, is that perhaps you could have the last middleman remailer send to a bunch of different randomly selected exitman remailers. So when you get some anonymous mail you get 10 copies of it. That way you can work out some stats for how likely someone who is operating 10 of 20 exit man remailers is to stop a given mail getting through. 1a) Counter-counter measure to 1) However if some of these remailers are operating from cracked accounts, rather than from anonymously purchased accounts, the attacker has an easy job of increasing his percentage of exitman remailers: take out the existing ones. Simple just email the admin of the cracked account -- he'll remove it. 2) Counter measure #2 Another idea, but really quite manual, would be to pick people who have advertised PGP keys, send them mail via some exitman remailer, and ask them politely to forward it to you. (Clearly sending through requests to "let me know if you recieve this email" aren't going to be recognized by the attacker, and let through if we send mail to people who don't have encryption capability). 2a) Counter-counter measure to 2) Course then the attacker can counter by letting through any encrypted mail without question. Stuck there aren't we :-( 3) Counter measure #3 Scraping the barrel here: what if we enlist the help of exitman remailers to check up on other exitman remailers? So now lets say we don't release a list of exitman remailers, but rather each exitman remailer privately announces itself to one randomly selected remailer privately. This is better in general because there is now no publically known list of exitman remailers. It is now harder for someone to use the list to just email all the admins in the hope that they will revoke paid for accounts (attacker makes legal threats, claiming to have receiving illegal material from this account or whatever), or to remove hacked accounts (real easy this one). With this setup we can send mail to one exit man via another one, with some chance that the first exitman won't recognize the other exitman. (You wouldn't want to overdo it with repeated mail, or the corrupt exitman might start to suspect the mail was another exitman). 3a) counter-counter measure to 3) It might be relatively easy for the well funded attacker to work out which addresses of those it receives to forward to are accounts with exitman installed. Eg. Watch the traffic from the host, after sending a bunch messages through remailers. Or simply finger the account see if the user ever logs in. (If it was hacked, it could be an active account, the user might never look at the forward file with |/home/oliver/... , nor the exitman remailer installed as "..." in some directory -- if it's working properly they won't see the email, and if it's forging email well they see replies). Incidentally exitman remailer hidden in "..." would allow a user to install it himself and plausibly claim ignorance, a more subtle way to obtain "disposable" exitman remailers. Best run from clearly non-technical users accounts with the knowing assistance of a technical assitant. 4) counter measure #4 An exitman remailer pinging service would be easily feasible for the post to USENET aspect (or to known mailing list), as the exitman remailer would show itself up quickly in this case. However I'm not sure this is so useful as mail2news gateways, and public postings generally (*) generate a lots less agro for their operators than a remailer. This is because people don't have to read USENET, and don't feel nearly so threatened as when they receive an anonymous mail aimed at them. And also because the mail2news gateway puts the senders address in the From field, which points the finger at the exit remailer anway. mail2news seems to be viewed as more neutral. If any mail2news operators have experiences which suggest otherwise I'd be interested to hear. (*) I did read of one case on remailer-operators where someone got hit by a remailer hater who used a remailer to post a fake advertisement of a CD full of commercial warez. The remailer-hater then anonymously tipped off the SPA. Incidentally I say "remailer-hater" here, but I should probably use a more term "remailer-attacker" or something, there could also feasibly be someone who is actually on our side (in a Zen sort of way) and trying to get us to face and solve the DoS and operators liability issues with technical solutions by demonstrating the current weaknesses. Some of these attacks are interesting for ordinary remailers also. Perhaps there exist right now normal (non-middleman) remailers which will send to another remailer in case it is a ping message, and anything that looks like an attempt to deliver to Raph, but junk the rest. Would we know? Anyway, overall I think the difficulty in checking on exitman remailers overall probably means that this simplest practical compromise for mail delivery from exitman remailers is for the last middle man remailer to send the mail to multiple exitman remailers. I also think the that the idea of exitman remailers privately announcing themselves to selected remailers might mean that they last longer, otherwise remailer haters will contact the admins and cause hassle even if they can't correlate any particular message came from a given remailer due to good mail forgery on the part of the exitman remailer. And using exitman remailers to post to USENET might be useful at some point if open access mail2news gateways got scarce.
When a email is chain-remailed and doesn't get delivered many, but not all, senders would simply assume one of the remailers are having delivery problems and resend. Will Raph's approach work to monitor decoys when their number and identity are constantly changing?
In theory yes. Send it via a couple of exitman remailers to make sure if you like. However the smart DoS attack described above is much harder to counter.
Won't this significantly complicate remailer clients?
Nope. The client won't need to know. You're not expected to send directly to an exitman remailer. That is something for remailer operators to use. You know how middleman operators work... they always, always send mail via another remailer and never deliver mail to a user. (I'm not sure if they detect this by looking to see if the address is on the remailer list, or just always add an extra hop?) So if there are some exitman remailers, a remailer operator that gets sick of the heat can switch to a new kind of middleman mode, where he always posts everything through various exitman remailers. (Or normal middleman mode, and leave the hassle of installing software to keep up to date on current exitmen to other exitman-using middleman remailers). Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`