From: Wei Dai <weidai@eskimo.com>
Date: Sun, 22 Oct 95 00:29:35 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re: Encrypted TCP Tunneler
In-Reply-To: <199510220102.SAA12922@jobe.shell.portal.com>
Message-ID: <Pine.SUN.3.91.951021233638.2645A-100000@eskimo.com>
MIME-Version: 1.0
Content-Type: text/plain


On Sat, 21 Oct 1995, Hal wrote:

> This has a lot of potential uses.  It would be good if chaining were
> possible, although that requires the client to double-encrypt.  That way
> it can let people connect out without local snoopers seeing where they
> are connecting.  However for this to work it is necessary that the DNS
> lookup be done by the server rather than the client, and for the
> destination (to which the server is supposed to connect) to be passed
> encrypted.

Thanks for the suggestions.  These features have already been implemented.
WRT to anonymity, I plan to add link encryption after releasing the first 
version.

> It should be noted that SOCKS V5 has basically the functionality that Wei
> is describing, but I am not sure whether any implementations exist.  It
> also has some other features which might not be appropriate for
> this use.  The purpose of SOCKS is to tunnel through firewalls.

I believe that using SOCKS requires changes to the application.  This 
will not be necessary with ETT, although as a price the user will have to 
do more work.  It may be possible to write a SOCKS to ETT adapter program.

> Unfortunately there is a also huge misuse of this program, as a
> connection laundry for breakin attempts.  Hackers already go through
> layer after layer of broken accounts, etc. to make tracebacks
> difficult.  Read Stoll's "Cuckoo's Egg" for one account.  I think the
> Mitnick story is similar.  These packet laundries would be extremely
> inviting for this purpose.  The first time the ETT server is the base
> of a lot of breakin attempts to military installations there is going
> to be trouble.  SOCKS provides a config file for servers to limit what
> kinds of connections will be allowed, but it is hard to see how to
> filter out the bad guys while letting people go through who are
> using services for which they are authorized.

ETT will allow the server to filter based on both the client's public key 
and the destination address.  I'm not sure how to implement this yet, but 
I hope to come up with a filtering scheme that will be general enough to 
be useful for many applications.

> Even if you don't try to provide anonymity with this service I think it
> is still going to be a problem if breakins come from the server.  By
> the time the traceback is initiated it is going to be a pain to figure
> out where the connection was coming from.  The service would be similar
> in this context to providing free guest accounts to which you could
> telnet in and then telnet out.  I think any site which did this (some
> used to in the relaxed old days) would take a lot of heat today.

I completely agree with you.  I don't think there will be many free 
public accessable ETT servers, because of the above reasons.  Most ETT 
servers will probably be operated for private purposes.  Those that are 
not should either charge money to cover their expenses and risk, or allow 
connections to only a small range of addresses or ports.

Wei Dai