Port 95 carries the SUPDUP protocol. If you've never heard of it, that's expected. SUPDUP has been effectively dead for decades. But it was once the most sophisticated way to connect to a remote computer, and it was born inside one of the most important operating systems in computing history.
What SUPDUP Does
SUPDUP stands for "Super-Display Protocol." It is a remote terminal access protocol, similar in purpose to Telnet, but designed to do something Telnet couldn't: understand what your screen could do.
When you connected to a remote machine via Telnet in the 1970s, the remote system had no idea what kind of terminal you were sitting at. Could it move the cursor? Could it clear a line? Could it insert text in the middle of the screen? Telnet didn't know and didn't care. It just sent characters.
SUPDUP solved this. When a SUPDUP client connected to port 95, the first thing it did was send a set of terminal descriptor variables: screen height, line width, scrolling behavior, and a detailed bitfield of capabilities. The remote system then knew exactly what your terminal could handle and sent display commands accordingly.1
This was device-independent graphics terminal output in 1977. The server didn't send raw escape sequences for a specific terminal model. It sent abstract commands: "move cursor here," "erase to end of line," "insert three blank lines." The client translated those into whatever its hardware understood.
The Protocol
SUPDUP listens on port 95 (TCP). The port number itself carries a piece of history: the original specification says the server listens on "socket 137 octal."1 The machines that ran SUPDUP were PDP-10s, and PDP-10 programmers thought in octal. 137 in base 8 is 95 in base 10.
After connecting, the client sends five 36-bit terminal descriptor variables, packed as six 6-bit bytes per word over the 8-bit connection:1
- TCTYP: Terminal type (set to 7 for the SUPDUP virtual terminal)
- TTYOPT: A bitfield of capabilities (can it erase selectively? Can it backspace? Does it have the Stanford/ITS extended ASCII character set?)
- TCMXV: Screen height in lines
- TCMXH: Line width in characters
- TTYROL: Scrolling glitch count
The server then sends output using %TD codes: abstract display operations like %TDMOV (move cursor), %TDEOL (erase to end of line), %TDCLR (clear screen), %TDILP (insert lines), and %TDDLP (delete lines). The protocol even supported 12-bit character input with "bucky bits" for CONTROL, META, and TOP modifiers, a precursor to the modifier key system still used in Emacs today.1
The Story
SUPDUP was not designed for the public Internet. It was designed for the hallways of the MIT Artificial Intelligence Laboratory.
In the late 1960s, MIT's AI Lab built an operating system called ITS, the Incompatible Timesharing System.2 The name was a joke. MIT's official timesharing system was called the Compatible Time-Sharing System (CTSS). The AI Lab hackers found CTSS too restrictive, too bureaucratic, too focused on keeping users in boxes. So they built their own system that was deliberately, proudly incompatible with institutional expectations.
ITS had no passwords. No access controls. No file permissions. Anyone could log in. Anyone could read any file. Anyone could modify any program. This was by design. The hackers at the AI Lab believed that openness accelerated progress, that the best code came from a culture where everyone could see, use, and improve everything.2
SUPDUP started as the internal protocol that ITS used to communicate between its own components and the "intelligent" terminals connected to it. When MIT's ITS machines were connected to the ARPANET, SUPDUP became the way users at one ITS system could use another ITS system's display capabilities over the network.1
RFC 734, the document that formally specified SUPDUP, was published on October 7, 1977, by Mark Crispin.1 Crispin was 21 years old, a systems programmer at Stanford University's Artificial Intelligence Laboratory (SU-AI). The RFC acknowledges Richard M. Stallman and David A. Moon of MIT for writing "the source documentation and the wonderful ITS terminal support that made this protocol possible."1
This was Mark Crispin's first RFC. Eight years later, at the same Stanford lab, he would invent the Internet Message Access Protocol, IMAP, the protocol that still delivers email to billions of people today.3 Crispin died on December 28, 2012, at the age of 56.3 Port 95 is the earliest artifact of his work on the protocols that shaped the Internet.
Security
SUPDUP has no encryption. No authentication mechanism. Every keystroke, every screen update, every command crosses the network in plaintext. This was not considered a flaw when it was designed. It was designed for ITS, a system that had no passwords to steal in the first place.2
Today, port 95 is considered an attack surface. The protocol is rarely used in production, but scanners still probe it. Any connection attempt to port 95 on a modern system should be treated as suspicious.4
SUPDUP was superseded by SSH (port 22), which does everything SUPDUP did and more, with encryption and authentication built in.
How to Check What's Listening on Port 95
On a modern system, nothing should be listening on port 95. If something is, investigate immediately.
Related Ports
| Port | Protocol | Relationship |
|---|---|---|
| 23 | Telnet | SUPDUP's predecessor, also unencrypted remote terminal access |
| 22 | SSH | SUPDUP's spiritual successor, with encryption |
| 143 | IMAP | Created by the same author, Mark Crispin |
| 95 | SUPDUP | The protocol described here |
Frequently Asked Questions
Was this page helpful?