3

VT100 terminals are "dumb terminals" - they just display data from the server, and send key strokes, with no local processing. In this setup, there can be server-side application flaws, and the connection is usually unencrypted. But the client isn't relied on for security controls.

Newer derivatives like VT220 introduced more control codes - colours, cursor control, primitive graphics. From basic reading on Wikipedia I can't see how they sent data up to the server. Is it still just direct key strokes, or some more structured protocol?

Someone mentioned to me informally that some of these protocols introduce client-side security controls. E.g. the screen would have several fields, some of which are read-only - and the control is enforced on the client. This would be interesting for security people, because a malicious client could bypass those controls. However, I can't find any information online to show this was in fact a problem.

I am asking for historic interest only. Do you know of any dumb-terminal related protocols where the client performs security controls?

2
  • Are you speaking of true hardware terminals, or emulators? Oct 29, 2016 at 15:12
  • @SergeBallesta - Either. If the protocol has controls for client-side security they would apply to both terminals and emulators.
    – paj28
    Oct 29, 2016 at 15:16

2 Answers 2

1

Although as noted in comments some terminals, notably IBM 3270-series (nicknamed 327X), did significant local 'editing' in order to reduce transmission and especially processing time, and as a convenience to users/operators, this was not designed or used as a security control.

The closest thing I can think of was that nearly all 'time-sharing' terminals then, like devices and most websites today, expected you to log-in with a password or similar once and thereafter permitted you to do various commands etc. defined by your log-in/userid for a fairly long period of time, so that if your terminal was not in a physically secured area and you left it to go to the bathroom or such while logged-in someone could use your logged-in session to do things they weren't authorized to do. But this seems so obvious I'm not sure it's an answer to your question.

3

In the old days, the grand father of all terminals was the Teletype model 33, one of the first ASCII capable terminal. AFAIK, the only protocol was:

  • send the ASCII code for any key pressed
  • print the character for any code received

It is still what is provided for dumb emulators. No security involved here.

They came terminal having screens. Manufacturer implemented various control codes to allow positioning the cursor on the screen and to allow some effects: blinking, dim or high intensity, reverse video and finally colours. More possibilities of presentation, but still no place for security.

With those terminals it was possible to use full screen editing (in the sense of what is allowed with curses and editors like emacs and vi) but all the presentation was done by the server. Some terminal manufacturers decided to implement a transactional model: the server sent a page, marking some zone as read-only and other as editable, the terminal displayed it and allowed operator to fill the editable fields locally and only when all the page was completed, the operator pressed a Send key and all the editable fields were sent to the server in once single operation. This allowed one single server to accept much more terminal.

But no security was involved either: the terminal were either local (hardwired) or connected through simple modems. The user was supposed to login when he first connected, full stop. All the security was at the application level on the server, because the equivalent of Javascript to send code to be executed on terminal did not exist.

8
  • Great answer, thank-you. The transactional model sounds interesting, do you know the name of any such protocol?
    – paj28
    Oct 29, 2016 at 18:08
  • 1
    Teletype 3X did not 'send both CR and LF'; instead essentially all computers were programmed to echo CR,LF when they received CR. If you used a Teletype in 'local' mode (not connected to computer) you had to actually press CR and LF in sequence. 33's did have an option when receiving ENQ aka ^E to send up to 20 characters from the 'answerback' drum, but this had to be pre-set manually with a pair of pliers; later TTY-style terminals often could remotely set the answerback, and that was occasionally used for pranks back in the days when hacking was done primarily for good. Oct 30, 2016 at 1:34
  • 1
    @paj28: although many other vendors used some terminals in 'form mode' or 'block mode' sometimes, the biggest by far was IBM's 3270 series terminals which were designed for and nearly always used in this mode, officially called 'formatted' or sometimes 'field-formatted'. Start with en.wikipedia.org/wiki/IBM_3270 and if you want more there are boatloads of old IBM manuals on all kinds of computing-history sites especially bitsavers.org. Oct 30, 2016 at 1:41
  • @dave_thompson_085 - Thanks for that, looks like 3270 is the answer. Can you make your comment an answer please.
    – paj28
    Oct 30, 2016 at 5:11
  • @paj28 it's an answer to your comment but not your question. 3270 local processing was intended to save comms and CPU cost (back then, CPUs were rented by the hour) and hopefully reduce data entry errors and improve productivity, not for security; host programmers were trained NOT to depend on terminal-side checks precisely because both the terminalsand the communication channels were not secure. Oct 31, 2016 at 1:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .