TLS provides strong protection for communication between pairs of entities. It allows you to perform authentication, data integrity protection, and data encryption. It is the successor to SSL, the secure sockets layer.
SSL was created at Netscape in the mid nineteen-nineties. TLS was created as a standardization of SSL 3.0; TLS version 1.0 was released in 1999. The latest version of TLS available with InterSystems IRIS is 1.2, often known as TLS v1.2. Among the supported versions of TLS for InterSystems IRIS® data platform, InterSystems recommends the use of the latest version available.
A TLS connection uses a client/server model; two entities establish a TLS connection through a TLS handshake. When two entities complete the handshake, this means that:
The client has authenticated the server.
If the server requires client authentication, this has happened. (If the client and the server have both authenticated each other, this known as mutual authentication.)
The client and server have agreed upon session keys. (Session keys are the keys for use with a symmetric-key algorithm that allow the entities to protect data during subsequent communications.)
Subsequent communication can be encrypted.
The integrity of subsequent communication can be verified.
The cipher suites of the client and server specify how these activities occur as part of the handshake or are supported for a protected connection. Specifically, a peer’s cipher suites specify what features and algorithms it supports. The client proposes a set of possible ciphers for use; from among those proposed, the server selects one. (If there are no common ciphers between the client and server, the handshake fails.)
To perform the handshake, TLS typically uses public-key cryptography (though it can use other means, such as the Diffie-Hellman protocol). With public-key cryptography, each peer (either the client or the server) has a public key and a private key. The private key is a sensitive secret value and the public key is a widely published value; typically, the public key is encapsulated in a certificate, which also contains identifying information about the holder, such as a name, organization, location, issuer validity, and so on. For InterSystems IRIS, a TLS configuration (described in About Configurations) specifies a named set of TLS-related values, including a certificate file, a private key file, and an optional set of cipher suites.
If successful, the handshake creates session keys that are used to protect subsequent communications.
While InterSystems IRIS and applications require various interactions with TLS, the end-user typically has no such direct interactions. For example, a browser uses TLS to establish a secure connection with a specified web site by requiring that the site (the server, in this case) authenticate itself to the browser (which occurs unbeknownst to the browser’s user) and the lock icon that appears in the browser is designed to indicate that TLS is protecting the connection.
InterSystems IRIS Support for TLS
InterSystems IRIS supports TLS to secure several types of connections:
From various client applications that interact with the InterSystems IRIS superserver (including ODBC, JDBC, and Studio).
From Telnet clients that interact with the Telnet server.
For use with TCP connections where an InterSystems IRIS instance is the client or server (or an InterSystems IRIS instance is at each end).
With the Enterprise Cache Protocol (ECP). For information on using TLS with ECP, see Securing Application Server Connections to a Data Server with TLS.
As a server, InterSystems IRIS accepts connections and establishes the use of TLS; as a client, InterSystems IRIS is able to connect to servers that require the use of TLS. In all cases, InterSystems IRIS uses what is called a TLS configuration, which specifies the various characteristics of an InterSystems IRIS instance as part of an TLS connection.