disposable remailers (was Re: Eternity Uncensorable?)

[Adam Back <aba@dcs.ex.ac.uk>]

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`