Encrypted TCP Tunneler

I am writting a program called Encrypted TCP Tunneler, which I hope to
finish in a month or so.  It will allow a secure link to be set up between
an ETT client and an ETT server, using Diffie-Hellman and DSA for
authenticated key exchange, and Blowfish for encryption.  A user will be
able to open a TCP connection to the client and have that connection
transparently tunnel across the secure link to a TCP address on the other
side. 

I see several uses for this program, such as secure telnet, secure web 
access, and access to a secure network across an insecure network.  I 
realize the program will no be as useful when IPv6 becomes widely 
available, but that may not happen for a while.  Also, this program can 
be used on top of IP security to give users (as opposed to system admins) 
more control over their own security.

Please send comments and suggestions.

Wei Dai

Tatu Ylonen (ylo@cs.hut.fi) wrote:
> You are aware that RSADSI claims they have exclusive licensing rights
> for DSA?

You are aware that Bidzos is full of shit?

Roger Schafly (sp?) addresses this issue in his lawsuit.  Hopefully this 
will be resolved soon.  The only problem is that Bidzo has made this claim 
on patents in other countries, not just USA, so he'd probably have to be 
sued throughout Europe also...  He sure does do a good job of making 
himself a pain in the ass even when he knows he's wrong.

Anyway, you could use ElGamal signatures instead, it is not patented.
The D-H and H-M patents do not cover digital signatures.

Wei Dai <weidai@eskimo.com> writes:

>I am writting a program called Encrypted TCP Tunneler, which I hope to
>finish in a month or so.  It will allow a secure link to be set up between
>an ETT client and an ETT server, using Diffie-Hellman and DSA for
>authenticated key exchange, and Blowfish for encryption.  A user will be
>able to open a TCP connection to the client and have that connection
>transparently tunnel across the secure link to a TCP address on the other
>side. 

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.

I should mention by the way that I don't share the general pessimism
towards anonymous TCP/IP connections.  While truly strong anonymity
against a hugely powerful opponent is difficult, I think a system like
what Wei is describing would still provide important privacy protections
as more people get hooked into the net.

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 see several uses for this program, such as secure telnet, secure web 
>access, and access to a secure network across an insecure network.  I 
>realize the program will no be as useful when IPv6 becomes widely 
>available, but that may not happen for a while.  Also, this program can 
>be used on top of IP security to give users (as opposed to system admins) 
>more control over their own security.

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.

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 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.

Hal

>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

alpha.c2.org will soon start provided anonymous web page
services.  You can get normal webserver access (the alpha.c2.org web
pages will be very limited) through an anonymous shell account.

> 
> >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
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

>alpha.c2.org will soon start provided anonymous web page
>services.  You can get normal webserver access (the alpha.c2.org web
>pages will be very limited) through an anonymous shell account.

>> 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.

How do you propose to protect entities wanting to utilise this function from

a) people sniffing the tcp packets coming in to discover who is maintaining
   a web page,

b) the above LEA attack where your own lines are monitored and data is tracked
   back thru the various networks to the web page maintainer?

c) an open LEA confrontation where they issue a warrant demanding any and all
   info you have on the web page maintainer. (e.g. co$ doesnt like whats on
   one of the pages)

The same again for the anon shell accounts.

Apart from a once off mailed to you via remailer, the creator of a web page
needs to maintain their creations. This implies a means of accessing it that
is repeatable. Wether thats via a dialup account or over the net, it can be
traced. It's only when the entity uses channels outside of the jurisdiction
or capabilities of those monitoring that some anonymity can be achieved.
(Implies they weren't monitored entering the blinding channels in the first
place).

Cheers,
Mark
mark@lochard.com.au

A) Maintanence requests come in through the remailer network. Someone
tcp sniffing my incoming network would only see SMPT packets coming
froma remailer.) and the SMTP messages would be encrypted with
alpha.c2.org's key.

B) See (A)

C) We don't keep any information about the owners of anonymous
accounts. We will gladly give up any information we have given a
properly executed court order. The important fact though is that we
don't have the information that an LEA would need to find the person
publishing the materials that the LEA doesn't like.



	The anon shell accounts are more difficult to secure.


> 
> >alpha.c2.org will soon start provided anonymous web page
> >services.  You can get normal webserver access (the alpha.c2.org web
> >pages will be very limited) through an anonymous shell account.
> 
> >> 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.
> 
> How do you propose to protect entities wanting to utilise this function from
> 
> a) people sniffing the tcp packets coming in to discover who is maintaining
>    a web page,
> 
> b) the above LEA attack where your own lines are monitored and data is tracked
>    back thru the various networks to the web page maintainer?
> 
> c) an open LEA confrontation where they issue a warrant demanding any and all
>    info you have on the web page maintainer. (e.g. co$ doesnt like whats on
>    one of the pages)
> 
> The same again for the anon shell accounts.
> 
> Apart from a once off mailed to you via remailer, the creator of a web page
> needs to maintain their creations. This implies a means of accessing it that
> is repeatable. Wether thats via a dialup account or over the net, it can be
> traced. It's only when the entity uses channels outside of the jurisdiction
> or capabilities of those monitoring that some anonymity can be achieved.
> (Implies they weren't monitored entering the blinding channels in the first
> place).
> 
> Cheers,
> Mark
> mark@lochard.com.au
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

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

Wei Dai writes:
> I am writting a program called Encrypted TCP Tunneler, which I hope to
> finish in a month or so.

I never finished my own implementation of IPSEC because I didn't have
time, but I am now in possession of a fully functioning version for
4.4BSD derived systems that was developed at NRL. I'm going to have it
integrated into the NetBSD source tree very soon.

I really encourage Wei and anyone else who's interested in this sort
of stuff to participate in the IPSEC work so that we can try to put
all our effort behind the one standardized solution -- it will make
interoperability much easier at the very least!

Perry

> an ETT client and an ETT server, using Diffie-Hellman and DSA for

You are aware that RSADSI claims they have exclusive licensing rights
for DSA?

Are you familiar with ssh [http://www.cs.hut.fi/ssh]?  It has many of
the features that you are planning.

    Tatu

On Mon, 23 Oct 1995, Tatu Ylonen wrote:

> > an ETT client and an ETT server, using Diffie-Hellman and DSA for
> 
> You are aware that RSADSI claims they have exclusive licensing rights
> for DSA?

Adding MD5 support wouldn't be a bad idea. Same for algorithms 
alternative to Blowfish (3DES etc.) and DH (e.g., with Elliptic 
functions-based key exchange), all automatically negotiated at connection 
time.

> Are you familiar with ssh [http://www.cs.hut.fi/ssh]?  It has many of
> the features that you are planning.

I think that Wei's idea is for something more general, similar to the
CryptoTCP 0.9 posted a few months ago by ModX and available from 
ftp://utopia.hacktic.nl/pub/replay/crypto/CRYPTOapps/ctcp.0.9.tar.gz
(that one used unauthenticated DH key exchange and 3DES, IMHO with a 
highly questionable PRNG for the generation of the session key).

It would be enormously more useful and popular if someone could write a
Winsock redirector loadable after WINSOCK.DLL but before any Winsock
application, hooking the API functions used to open TCP connections. That
would mean instant transport-level crypto capability for most Winsock
apps, just like NEC's SocksCap provides instant SOCKS (alas, V.4)
compliance. 

Also Perry's invitation to join the IPSEC effort should be given proper
attention (I would do it, if only my spare time were not in such short
supply). I would try to implement it on SLiRP, a free SLIP/PPP simulator
largely based on BSD TCP/IP code (but running in user mode). That would
allow to experiment without having to hack the kernel, and would have a
practical value for converting conventional login accounts into
IPSEC-compliant SLIP/PPP accounts (instant crypto, again). Networking
technologies gain much faster popularity once a critical mass of users
actually use them. And to reach that mass, we must enlist all the 
non-techies who just run unmodified Windows applications.

Enzo

On Mon, 23 Oct 1995, Enzo Michelangeli wrote:
> Adding MD5 support wouldn't be a bad idea. Same for algorithms 
> alternative to Blowfish (3DES etc.) and DH (e.g., with Elliptic 
> functions-based key exchange), all automatically negotiated at connection 
> time.

Starting to sound like you want the crypto layer to be SSL (v3 for DH) or
PCT :-).

eric

On Mon, 23 Oct 1995, Tatu Ylonen wrote:

> Are you familiar with ssh [http://www.cs.hut.fi/ssh]?  It has many of
> the features that you are planning.

I saw the announcement for ssh a while ago, but didn't get a copy because
it doesn't run under MS Windows.  I just downloaded a copy today and read
some of the documentation.  It apparently has many of the features I
talked about, plus lots more. 

However, I probably won't give up ETT yet, because there are some design 
differences that would make ETT more useful in certain circumstances.  
SSH seems to be design mainly as a secure telnet program, with TCP port 
redirection added on, which suggests (although I'm not sure) that you 
need to have an user account on the SSH server to connect to it.  It also 
does not seem to do any filtering of TCP redirection requests.  Chaining 
would not work well with SSH because of its packet overhead.

I'll try to get SSH working soon, but so far I am very impressed with it.
I am curious, however, about your choice of key exchange and
authentication schemes.  What are the relative advantages of your protocol
over a more straight-forward DH + signature of exchange values?  DH would
provide forward secrecy directly without the need to change the server key
every hour. 

Wei Dai

Hi,

i am using a prog called twinsock to have an internet connection via my 
shell account. The program provides a winsock for my windows progs and it 
comes with the complete source. When I first started to use it, I thought 
that it must be fairly easy to add some packet encryption to this 
program. But then I realized that it wouldnt work over a tcp/ip 
connection, only over a telephone line. But maybe the twinsock code might 
be a good starting point for some encrypting winsock. Unfortunately, I am 
not a good enough programmer to estimate how much work it is to come up 
with such an enhanced winsock or even start to make one myself.

Stephan

> However, I probably won't give up ETT yet, because there are some design 
> differences that would make ETT more useful in certain circumstances.  
> SSH seems to be design mainly as a secure telnet program, with TCP port 
> redirection added on, which suggests (although I'm not sure) that you 
> need to have an user account on the SSH server to connect to it.  It also 
> does not seem to do any filtering of TCP redirection requests.  Chaining 
> would not work well with SSH because of its packet overhead.

You are quite right here; some kind of account is needed on the
forwarder machine.  (It can, though, be an account without password
and a login shell that just sleeps.)  But anyway, TCP port forwarding
is not its main function.  (I don't think the packetizing is such a
major overhead though - it currently transfers around 400kbytes/sec
over ethernet encrypted with RC4 between P90 machines.)

> authentication schemes.  What are the relative advantages of your protocol
> over a more straight-forward DH + signature of exchange values?  DH would
> provide forward secrecy directly without the need to change the server key
> every hour. 

The reasons for this key exchange are mostly historical.  If I was
starting the implementation now, I would use DH + signatures.  The
performance difference is not very big, but DH + signature would be simpler.

    Tatu