Telnet Encryption


This document describes a bit about the telnet protocol and how the Carnegie Mellon SCS Facilities has configured our Unix machines to use the telnet protocol.

Contents


Telnet Security

When you telnet from one machine to another, the information is sent across the network. It is possible that other machines on the same piece of network can watch the traffic as it is exchanged between two machines.

If encryption is not negotiated in the telnet protocol, the traffic is not encrypted and it can be quite easy for other machines on the same network to eavesdrop on the communication and record such things as passwords and other sensitive data. The person doing the eavesdropping might later use this information to

This eavesdropping is not a theoretical attack. It is something that has happened multiple times in our facility. If you send your password across the network without some sort of encryption, your password will be compromised. If you routinely send your password across the network without encryption, your machines could already be compromised.


Kerberos Authentication

The telnet protocol has the ability to negotiate an authentication mechanism. We have configured the telnet client program on most of our Unix machines to use kerberos authentication if it is available. The encryption mechanism in our telnet program is based upon a shared secret. This shared secret is based upon kerberos authentication.

You can use the program "klist" to see if you have kerberos tickets. If you have tickets, you should see a result of something like

/usr/local/bin/klist
Ticket file:    /tkt/195t15988
Principal:      bovik@CS.CMU.EDU

  Issued           Expires          Principal
Feb 11 12:34:31  Feb 15 07:11:24  krbtgt.CS.CMU.EDU@CS.CMU.EDU
Feb 11 12:34:32  Feb 15 07:11:25  afs@CS.CMU.EDU

If you do not have kerberos tickets the results of klist might look like this

/usr/local/bin/klist
Ticket file:    /tkt/195t15988
klist: You have no tickets cached

Encryption

The encryption in telnet is based upon a shared secret key, not a public/private key system. The shared secret is established with kerberos authentication. If you do not have valid kerberos tickets, you can not establish a secure and encrypted connection with our current telnet client or telnet server programs.

To use telnet client program, type:

telnet -a hostname

This will attempt to establish an encrypted telnet connection to hostname and automatically log you in without typing a password. (This procedure will not give you kerberos tickets on the remote host; you must use kinit.)

It is a good idea, though, to set up your environment so that you always get positive confirmation of encryption, which you can do in your .telnetrc file in your home directory. You can use the same file to attempt automatic login when you use telnet, and to make sure telnet always uses encryption. Put the following lines in your

~/.telnetrc

file (be sure to indent as shown):

DEFAULT
        set verbose_encrypt
        set autoencrypt
        set autodecrypt

You can also make secure kerberos-encrypted telnet connections from the following outside kerberos realms:

ANDREW.CMU.EDU
CLUB.CC.CMU.EDU
DEMENTIA.ORG
ATHENA.MIT.EDU
ECE.CMU.EDU
TRANSARC.COM
PSC.EDU

If you dont have a secure connection the client program will issue a warning of the form

Client Warning: Connection not encrypted! Communication may be eavesdropped.

This means that the telnet program has decided that anything you type will be sent across the network in the clear. If you see this message anything you send or receive across that connection can be easily compromised.

If you telnet to one of our machines, the telnet server will also check to see if the connection has been encrypted. If the telnet server decides that the connection has not been encrypted, it will issue the warning

Server Warning: Connection not encrypted! Communication may be eavesdropped.

Again, anything you send or receive across that connection can be easily eavesdropped, including any passwords you might type.

To enable encryption requires not just a telnet client or telnet server that is capable of doing authentication and encryption, it requires both the client and the server be able to negotiate these options. If you are off site and the machine you are using does not have a version of telnet with these authentication and encryption features, then you will not be able to use telnet to get a secure connection to one of our machines.


Quirk Configuration

Whether the telnet server requires encryption depends upon a configuration of the server machine. The server machine is the machine that you telnet to, not the client machine that you telnet from.

This particular configuration mechanism we call a quirk. If there exists a quirk key named telnetd_force_encrypt that is turned on, then all telnet connections to that machine must be encrypted. Normal or unencrypted connections are rejected as being unsuitable because of security concerns.

There are four different files that store these quirk configuration options

A quirk configuration option can be set in any of the above files. But we recommend that you only modify the /etc/quirk.local file. The other three will be maintained, modified, and automatically replaced without prior notification. The local quirk file will generally not be automatically replaced.

A quirk file is a sequence of lines. Anything on a line following the character

#

is ignored. A line is either empty or a key value pair. A key value line is of the form

key = value

White space before and after the key is ignored. White space before and after the value is ignored.

If the same quirk key has different values in different quirk files, the value from the file with the highest precedence is used. The precedence from highest precendece, to lowest is

This allows the local configurations to easily override any system specific or global default configurations.


Requiring Encrypted Connections

It is possible to configure the telnet server on Carnegie Mellon SCS facilities supported unix machines so that only encrypted connections are allowed.

If either the client or the server does not negotiate an authenticated and encrypted connection, the server will terminate the connection. Currently if the connection must be encrypted, it might look something like this

Escape character is '^]'.
Client Warning: Connection not encrypted! Communication may be eavesdropped.
Server Warning: Connection not encrypted! Communication may be eavesdropped.
[ Encryption was required; For additional information see
  http://www.cs.cmu.edu/~helpext/telnet.html
  good-bye. ]

When the telnet server starts, it checks the quirk key named "telnetd_force_encrypt" to see if it should allow unencrypted connections.

To enforce that only secure encrypted telnet connections to your unix machine, have root or the system administrator put the line

telnetd_force_encrypt=on

in the file /etc/quirk.local .

To allow unsecure connections, where anyone can see your password, put the line

telnetd_force_encrypt=off

in the file /etc/quirk.local .


For help with any facilities-related problem, please contact help@cs.cmu.edu. If you have questions and comments regarding this documentation, please send mail to help+doc@cs.cmu.edu