The Trial of Telnet

"Will the defendant please rise?"

Picture this: You're working on your MultiValue system happy as a clam and all of a sudden something in the network hiccups and you instantly find your Telnet session disconnected, never to return. Or maybe you're one of the unfortunate many who have had your credentials or credit card number sniffed off the network and used improperly?

Though the Telnet protocol has been a mainstay of communicating with MultiValue systems for decades, perhaps it's time to take a fresh look at the good, bad, and ugly of Telnet and see where this seemingly simple protocol fits into our otherwise bright MultiValue future.

The Good

For those raised on Unix, Telnet seems simple enough. Open up a client, request a connection, and you're right there in your MultiValue application. Even Windows platforms have Telnet servers to service their MultiValue databases. And with some of the GUI toolkits available today, MultiValue applications can present a pretty nice façade to our customers.

Telnet is a reasonably lightweight protocol. When there's nothing going on, there is very little traffic on the network. (Some, yes, but it's very little.) Telnet packets also include a minuscule amount of overhead to move their payload on the wire.

Common Telnet clients today support a dizzying array of terminal emulations to offer the widest compatibility for our MultiValue applications. Applications written decades ago for Wyse50's, VT220's, and other terminal devices can run on these emulators almost as if the user were using the real thing.

The Bad

Let us not forget, however, that not only is Telnet nearly thirty years old and growing older by the minute, the devices that are being emulated have been antiques for quite a while. So while there's been real financial value in maintaining at least a reasonable emulation of these older devices, for how long will we be tethered to emulations of antiques? Our applications deserve better, do they not?

While the Telnet protocol itself is reasonably lightweight, there is still the need for hardware to support multiple simultaneous persistent connections. Connect 600 users to a system and there'll be 600 persistent processes running Telnet (plus a MultiValue shell for each) to service those users. Maybe each connection does not use much, but with each of those processes taking a little bit of memory, a little bit of CPU, and a little bit of the network bandwidth, it's not unreasonable to expect that it all adds up somewhere.

It's also worth mentioning that the number of new Telnet clients being added to the market is remarkably small. There's a reason for this — In my opinion the Telnet protocol itself is ambiguously specified, remarkably complex to implement completely and correctly, and there's rarely anything new in emulating hardware that is more commonly found in the Smithsonian archives than in production use.

Everyone has suffered through a Telnet dropout at one time or another. There are some proxy programs available that will restore a failed Telnet connection by standing in the gap between the server and client. But these tools are still rare, with most people accepting the occasional dropout and ensuing frustration as a fact of life in the total cost of Telnet ownership.

Finally, no matter how good they are, Telnet clients appear only infrequently in the global technology landscape. Furthermore the really good Telnet clients can be a bit pricey, especially when being purchased for the constituency of larger organizations.

The Ugly

If you're confident your information is secure, download, install, and run a little free program called WireShark (http://www.wireshark.org). WireShark is a TCP/IP packet sniffer that will show you in colorful detail the information that is being sent across your network. Want to know who's using the most bandwidth? WireShark will show you. Want to know who is connecting to where and how often? Wireshark has that information. Or maybe you're interested in the actual data coming from and going to all those Telnet clients? It's all right there in living color in WireShark.

Virtual Private Network (VPN) connections definitely improve the security of information coming in and going out of our networks. But once on the corporate side of the VPN, all that information continues to flow unsecured from the VPN endpoint to and from our servers. Please understand, VPNs are great and essential tools. But a VPN is only secure on the connection itself. Anything before or after the VPN endpoints is not implicitly secure.

The Verdict

If you had an employee that unexpectedly dropped off the grid from time to time and was a security risk with sensitive information, would you want to hire a hundred or more just like that person? Yet, this is the choice we make each day by continuing a commitment to the Telnet protocol.

The Options

SSH is more secure, but not necessarily more reliable, and there are few SSH clients that support all of the terminal emulations we typically use. Telnet with SSL support is also more secure but amazingly rare, and it also does nothing to improve the reliability of the connection between the client and server.

Unfortunately, this reliability issue is not a simple problem as it is predicated on miles of cable and countless pieces of equipment that may be out of our immediate control. Nobody knows when a work crew will inadvertently drill through a cable or DSN line while planting a tree or rewiring a neighborhood. But could it be that our reliability concerns are predicated — if even in part — on our desire for persistent Telnet connections to our servers? Furthermore, if we reduced our need for persistent Telnet connections, might we implicitly improve reliability?

I believe the answer to both questions is "yes" and will explore these options in more detail next issue.