The IBM 3270 is a class of terminals made by IBM since 1972 (known as "display devices") normally used to communicate with IBM mainframes. As such, it was the successor to the IBM 2260 display terminal. Due to the text color on the original models, these terminals are informally known as green screen terminals. Unlike common serial ASCII terminals, the 3270 minimizes the number of I/O interrupts required by accepting large blocks of data known as data streams, and uses a high speed proprietary communications interface, using coax cable.
IBM stopped manufacturing terminals many years ago, but the IBM 3270 protocol is still commonly used via terminal emulation to access some mainframe-based applications. Accordingly, such applications are sometimes referred to as green screen applications. Use of 3270 is slowly diminishing over time as more and more mainframe applications acquire Web interfaces, but some web, IVR and call center applications use the technique of "screen scraping" to capture old screens and transfer the data to modern front-ends. Today, many sites such as call centers still find the "green screen" 3270 interface to be more productive and efficient than spending resources to replace them with more modern systems.
3270 devices include a series of display devices, communications controllers, and printers that connect to an IBM mainframe. They support a special type of data stream, which is called the 3270 data stream. This data stream allows applications to include control characters that instruct the receiving device how to format or display the information. The control characters allow the application to use the entire screen, as opposed to a single command line, to display information and to receive input from various areas of the screen (called partitions).
SNA 3270 refers to 3270 data streams that are transported from the source to the destination using the SNA protocol. With SNA 3270, the data stream is transmitted over an LU-to-LU session between logical units. LU types 2 and 3 use only SNA 3270 data streams. LU types 6.1 and 6.2 use the SNA 3270 data stream in addition to other types of data streams.
With SNA 3270, the mainframe application creates a 3270 data stream using 3270 commands, the data stream is transported over an SNA network, and the data is displayed on a 3270-compliant device.
TN3270 is a protocol that defines how to transport 3270 data streams over a TCP/IP network. TN3270 was originally defined in RFC 1576 and is based on the Telnet protocol. The difference between a Telnet session and a TN3270 session is that a Telnet session uses the ASCII character set and sends a line of data at a time and a TN3270 session uses the EBCDIC character set and sends a block of data (a screen refresh) at a time.
The following elements work together to enable TN3270 communication:
In an SNA 3270 network, the user is known by the LU name. In a TCP/IP network, the user is known by an IP address. One of the tasks of the TN3270 server is to provide a correlation between these two addresses. This correlation allows the SNA applications to maintain the LU requirements and allows the network to use IP.
TN3270, as defined by RFC 1576, does not address several functions that are required to make the TN3270 server a viable migration solution. To address this problem, TN3270E was defined under RFC 2355 (which made obsolete RFC 1647). TN3270E added the following functions:
Transport Layer Security (TLS) and its better known predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security and data integrity for communications over TCP/IP networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. Several versions of the protocols are in wide-spread use in applications like web browsing, electronic mail, Telnet, Internet faxing, and voice-over-IP (VoIP).
In typical client usage, TLS/SSL authentication is unilateral: only the server is authenticated (the client knows the server's identity), but not vice versa (the client remains unauthenticated or anonymous). At the client level, the client validates the server's certificate — i.e., checked the digital signatures of the server certificate's issuing CA-chain (chain of Certification Authorities that guarantee bindings of identification information to public keys — see public key infrastructure).
TLS/SSL involves three basic phases:
During the first phase, the client and server negotiate cipher suites, which determine the ciphers to be used, the key exchange and authentication algorithms, as well as the message authentication codes (MACs). The key exchange and authentication algorithms are typically public key algorithms. The message authentication codes are made up from cryptographic hash functions using the HMAC construction for TLS, and a non-standard pseudorandom function for SSL.
The Cleo "client" supports the following encryption algorithms:
The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet.