cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1995-10-22 - Re: Encrypted TCP Tunneler

Header Data

From: Mark <mark@lochard.com.au>
To: hfinney@shell.portal.com (Hal)
Message Hash: 7776c374db4acc9e7bfacae3b3e48e39023f22193ebf9deaa8ebae4a8ae93ed9
Message ID: <199510220058.AA44534@junkers.lochard.com.au>
Reply To: <199510220102.SAA12922@jobe.shell.portal.com>
UTC Datetime: 1995-10-22 02:33:33 UTC
Raw Date: Sat, 21 Oct 95 19:33:33 PDT

Raw message

From: Mark <mark@lochard.com.au>
Date: Sat, 21 Oct 95 19:33:33 PDT
To: hfinney@shell.portal.com (Hal)
Subject: Re: Encrypted TCP Tunneler
In-Reply-To: <199510220102.SAA12922@jobe.shell.portal.com>
Message-ID: <199510220058.AA44534@junkers.lochard.com.au>
MIME-Version: 1.0
Content-Type: text


>I was toying with a limited form of this idea earlier, where outgoing
>connections would be limited to http servers.  These are usually on a
>small number of ports, although there are exceptions.  At least it
>would be possible to filter out telnet and rlogin and such for that
>application.  I don't think there are too many bad things you can do
>just by connecting to httpd ports (probably I would be surprised,
>though...).  But doing that would not make as much sense for the ETT
>application.

A more cypherpunky type of application would be to enable anonymous
httpd's so that your clients could advertise their nice/naughty products
and be safe from location identification. If they had to pack up then
they could move to another ISP and reconnect to the anon.net as normal.
(Didnt I just read this in a spam HOWTO?)

The problem I see is when a LEA gets involved and snoops your wires and
traces you back to your starting point and then traces the client that is
supplying nasty httpd services. You wouldnt necessarily be aware of this
occuring either.

Mark

Thread