forrest@CSA3.LBL.GOV (11/10/88)
I am a complete novice at matters relating to networking and haven't read the Telnet RFC so I may be missing something obvious. Assume the following network organization: A <------------------> M <------------------> Z (Node M is actually one or more gateways.) Couldn't a bad guy on M monitor the TCP/IP traffic looking for Telnet connections and then follow through the exchange of login names and passwords, thereby capturing a node/login and password pair? (I realize that the path from A to Z is dynamic and that this might not always be possible.) Jon Forrest Lawrence Berkeley Lab FORREST@LBL.GOV
stev@VAX.FTP.COM (11/17/88)
*A <------------------> M <------------------> Z * *(Node M is actually one or more gateways.) Couldn't a bad guy on M *monitor the TCP/IP traffic looking for Telnet connections and then *follow through the exchange of login names and passwords, thereby *capturing a node/login and password pair? (I realize that the *path from A to Z is dynamic and that this might not always be *possible.) * *Jon Forrest *Lawrence Berkeley Lab *FORREST@LBL.GOV yep. even on a single ethernet someone could use a lan monitor to catch your passwords as they fly over the net. i believe the Athena people use Kerberos (sorry about butchering the spelling) to deal with some of this. (or at least they could . . . . .) network security is a very big fish to try and fry. basically, the whole system would have to be re-done. i would think that we would want to use diffrent "well known ports" for the new secure versions. and forget IP security. if the packet is on my wire, i can see it. IP security is only good if all the machines respect it. ( a friend told me the only real-world use he saw for IP security was internet wide poker games). perhaps a kerberos type of scrambling on a host basis rather than a connection basis (the host has a public key assigned to it). if you try this, you can skip messing with the programs, and put the unscrambler between the network code and the application. ( i suppose you could even make it an IP option. then you could even protect the tcp layer from prying eyes.) this *will* add to the overhead, though. i havent really thought about this alot, and am not sure if it is the "right thing to do" yet or not. ah, well, too late now, i suppose . . . (the "purists" will probably not like this.) (*sigh*) stev knowles ftp software stev@ftp.com 617-868-4878
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/20/88)
In article <881109143927.20402284@Csa3.LBL.Gov> forrest@CSA3.LBL.GOV writes:
I am a complete novice at matters relating to networking and haven't
read the Telnet RFC so I may be missing something obvious.
No question is unworthy of asking.
Assume the following network organization:
A <------------------> M <------------------> Z
(Node M is actually one or more gateways.) Couldn't a bad guy
on M monitor the TCP/IP traffic looking for Telnet
connections and then follow through the exchange of login
names and passwords, thereby capturing a node/login and
password pair? (I realize that the path from A to Z is
dynamic and that this might not always be possible.)
Yes. In fact if one has a LAN sniffer one can read the entire
traffic on the EtherNet Cable. All networking schemes assume
physical secuirty of the communications media.
The DoD people have a solution: encrypt the comm-line. There is
a secure version on the Internet that does just that. Even
better is to use end-to-end encryption for each communications
circuit. The basic problem with all of this is the encryption
overhead and the key and authentication problems.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.comkwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (11/23/88)
In article <2215@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >In article <881109143927.20402284@Csa3.LBL.Gov> forrest@CSA3.LBL.GOV writes: > (Node M is actually one or more gateways.) Couldn't a bad guy > on M monitor the TCP/IP traffic looking for Telnet > connections and then follow through the exchange of login > names and passwords, thereby capturing a node/login and > password pair? (I realize that the path from A to Z is > dynamic and that this might not always be possible.) > >The DoD people have a solution: encrypt the comm-line. There is >a secure version on the Internet that does just that. Even >better is to use end-to-end encryption for each communications >circuit. The basic problem with all of this is the encryption >overhead and the key and authentication problems. Link encryption won't solve this problem. The two links are encrypted independently and someone with access to the system M could still pick up traffic and snoop ids and passwords. You need either a trusted router (trusted network actually); or application layer encryption, which is not part of telnet, to avoid snooping from inside the network. Secure networks or secure applications. Better both.
jfc@athena.mit.edu (John F Carr) (11/23/88)
In article <8811162311.AA09389@vax.ftp.com> stev@VAX.FTP.COM writes: >yep. even on a single ethernet someone could use a lan monitor to catch >your passwords as they fly over the net. i believe the Athena people >use Kerberos (sorry about butchering the spelling) to deal with some >of this. (or at least they could . . . . .) Kerberos does provide for encrypted connections (the Kerberos server generates a random session key for use by the client-service pair [this key is encrypted using the user and/or service key when it is sent over the net]). To the best of my knowledge, there is only one program that uses it (an encrypted version of rlogin). Kerberos authenticated login cuts down on the need to type passwords over the net. As long as the remote host accepts authenticated rlogin AND you do not need a set of tickets on that host, your initial tickets are sufficient. There are some cases when Kerberos is insufficient (the issue of ticket forwarding [getting tickets valid on a remote host without entering a password] is not yet solved; the security tradeoffs are a problem). >i would think that we would >want to use diffrent "well known ports" for the new secure versions. That is what is done with Kerberos. -- John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, bloom-beacon! Will they read of us with sadness athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peart