During the initial connection handshake with a Telnet server there is an optional exchange of options that tell the client/ server which features are supported on both ends. These features are negotiated using the DO, DONT, WILL and WONT Telnet options.

In case you're not familiar with the DO, DONT, WILL and WONT Telnet options here's an excerpt taken from the official RFC 854:

• WILL: Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option.
• WONT: Indicates the refusal to perform, or continue performing, the indicated option.
• DO: Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option.
• DONT: Indicates the demand that the other party stop performing, or confirmation that you are no longer expecting the other party to perform, the indicated option.

Shodan has been crawling and storing the results of the Telnet handshake for a while now but never made it accessible over the search API/ interface. That's changed and now there are the following new filters and facets:

• telnet.option
• telnet.do
• telnet.dont
• telnet.will
• telnet.wont

These Telnet facets/ filters provide a new way to discover and fingerprint devices. The telnet.option filter/ facet includes all the options that a server knew about, whether they were sent in the DO, DONT, WILL or WONT phase. I.e. it aggregates the results of all the other options into a unique list of features a server is aware of. The other filters/ facets relate directly to the options outlined in the RFC and let you find servers that support specific functionality. For example, here are servers that know about the com_port_option.

Telnet remains a popular service that continues to get deployed and integrated across a variety of products, including the latest in Internet of Things devices. The new features should make it easier to uniquely fingerprint devices and keep track of how Telnet usage is changing over time.

I've recently started to try out various smart home products, and while browsing the community pages of SmartThings I found a curious case:

http://community.smartthings.com/t/telnet/222

This quote in particular stood out to me because it exemplifies why I believe Telnet remains a popular protocol among vendors, users and even software engineers:

All of lutron products uses telnet access to send and receive info from the lutron system. The commands have a really quick learning curve for many to learn and are extremely powerful.

Any word if the SmartThings hub will allow me to send telnet commands out of it?

I can't fault the user for loving Telnet, since it comes pre-installed on a lot of operating systems and working with it is incredibly straight-forward. It's so easy to work with for this user that he would like the IoT vendor include a Telnet client on the device, so he can integrate the hub with his lighting system. Hmmm, well what about Lutron? Maybe this user has some old products of theirs installed and Telnet has long been deprecated. Nope (pdf), even the latest documents on how to integrate Lutron devices references their Telnet server.

Maybe this manufacturer is just behind the times, which isn't unusual for embedded systems, so what about mobile app developers?

GCDTelnetServer is a drop-in embedded Telnet server for iOS and OS X apps.

The GCDTelnetServer is actually a cool little project that's probably immensely useful, and Telnet just happened to be the easiest way to implement it. As a sidenote, if anybody is aware of a similar project done without Telnet please let me know!

The fact that Telnet is easy to use, easy to integrate and is being demanded by users results in the fact that Telnet continues to thrive on the Internet.

The above image shows the breakdown of data collected from Shodan for the month of March. The top 10 services are:

1. HTTP
2. CWMP
3. SIP
4. SSH
5. HTTPS
6. Telnet
7. HTTP (8080)
8. UPnP
9. SMTP
10. FTP

Obviously, there are a lot of legacy devices that use Telnet and are being phased out in favor of SSH so it's not entirely clear how often Telnet is chosen for new products. But it remains a fact that even for new programs and devices, people and engineers are chosing Telnet over alternatives. It will be important to keep track of these usage numbers over time, and hopefully the developer/ user ecosystem will get better so using Telnet will seem insane not just from a security perspective but also from a usability standpoint.