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
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
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
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:
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
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
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
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
participants (10)
-
anon-remailer＠utopia.hacktic.nl -
Enzo Michelangeli -
Eric Young -
Hal -
Mark -
Perry E. Metzger -
sameer -
someone -
Tatu Ylonen -
Wei Dai