Configuring and Using Security for Z and I Emulator for Windows

Z and I Emulator for Windows provides session security using Microsoft CryptoAPI (MSCAPI). These packages enable use of the Transport Layer Security (TLS) security protocols.

The configuration information in this chapter usually applies to TLS. See Using Transport Layer Security for more information.

You can display information about the security aspects of your session by clicking Communication -> Security Information from the session menu bar. This provides details about the certificates exchanged during TLS negotiations between client and server.

A TLS session is established in the following sequence:

  1. The client and the server exchange hello messages to negotiate the encryption algorithm and hashing function (for message integrity) to be used for the session.
  2. The client requests an X.509 certificate from the server to verify the identity of the server. Optionally, the server can request a certificate from the client (known as Client Authentication).

    The digital signature of the certificate authority (CA) is authenticated using a published root certificate of the issuing CA. The client automatically decrypts certain information on the presented certificate using a public key on the CA's root certificate. This step is successful only when the presented certificate was encrypted using a well-guarded, unique, and corresponding private key, known only to the CA. This process can detect (and reject) intentional alterations (forgeries) and the rare garbling that can occur over data circuits. Z and I Emulator for Windows also allows users to use self-signed certificates for this purpose.

  3. Once the certificate-issuer authentication step succeeds, the client and server negotiate for an encryption key to be used during the ensuing data exchange session. The client randomly generates a set of keys to be used for encryption. The keys are encrypted with the server's public key and are securely communicated to the server.

When a secure connection is established, a padlock icon is displayed in the Z and I Emulator for Windows status bar. Depending on the level of encryption, the icon is accompanied by a number (0, 40, 56, 128, 168, 256). If the session is not TLS-based, the icon shows as unlocked.

Certificates

Security is controlled by digital certificates that act as electronic ID cards. The purpose of a certificate is to assure a program or a user that it is safe to allow the proposed connection and (if encryption is involved) to provide the necessary encryption/decryption keys. They are usually issued by Certificate Authorities (CAs), which are organizations that are trusted by the industry as a whole and who are in the business of issuing of Internet certificates. A CA's certificate, which is also known as a root certificate, includes the CA's signature and a validity period, among other things.

Encryption and authentication are performed by means of a pair of keys, one public and one private. The public key is embedded in a certificate, known as a site or server certificate. The certificate contains several items of information, including the name of the Certificate Authority (CA) that issued the certificate, the name and public key of the server or client, the CA's signature, and the date and serial number of the certificate. The private key is created when you create a self-signed certificate or a CA certificate request and is used to decrypt messages from clients.

Managing Certificates in the Microsoft Certificate Stores

In order to connect secure sessions using the Microsoft CryptoAPI (MSCAPI) security package, the appropriate certificates must exist in the Microsoft Certificate Stores. To connect to a secure host, the root certificate of the host certificate's verification chain must be in the Trusted Root Certification Authorities store. To connect a secure client authentication session, the client certificate must be in the Personal store.

To add, remove, and view certificates in the Microsoft Certificate Stores, select Internet Options in the Windows Control Panel. On the Content tab, click Certificates. The tabs represent the different Microsoft Certificates Stores. Each tab shows the certificates that exist within each store.

To add a certificate to a store, click Import; the Certificate Import wizard helps you import certificates from a file. The Import wizard can import certificates from several types of certificate files, including the ARM, DER, and P12 formats that can be extracted or exported from the Certificate Management utility.

Configuring and Using Secure Sockets Layer

The purpose of basing communications on TLS is to provide privacy and integrity during communication over an unsecured TCP/IP connection between a client and a target server. This section briefly describes how to configure the Z and I Emulator for Windows client to use this mode.

Preparation for TLS Communication

There is a division of labor for TLS configuration tasks. The configurations of the client and the server are coordinated to achieve the required compatibility. The following sections describe the preparation tasks required for client configuration and server configuration.

Client Configuration

The following elements must be configured on the client side to enable TLS:

To add, remove, and view certificates in the Microsoft Certificate Stores, select Internet Options in the Windows Control Panel. On the Content tab, click Certificates. The tabs represent the different Microsoft Certificates Stores. Each tab shows the certificates that exist within each store.

Establishing a Secure Session

Upon establishing a preliminary connection with a target server, the Z and I Emulator for Windows client is presented a certificate by that server; if you have enabled client certificate authentication, your certificate is likewise presented to the server. The digital signature of the CA is authenticated using a published root certificate of the issuing CA. The client automatically decrypts certain information on the presented certificate using a public key on the CA's root certificate. This step is successful only when the presented certificate was encrypted using a well-guarded, unique, and corresponding private key, known only to the CA. This process can detect (and reject) intentional alterations (forgeries) and the rare garbling that can occur over data circuits.

Z and I Emulator for Windows also allows users to use self-signed certificates for this purpose.

Note:

Once this certificate-issuer authentication step succeeds, the client and server negotiate to agree on an encryption key to be used during the ensuing data exchange session.

Configuring Z and I Emulator for Windows Session Security

Whether you are configuring a TN3270, TN5250, or VT session, the underlying protocol must be TCP/IP. Use the following procedure to enable security:

  1. Start a workstation profile from the Session Manager; or, from an active session, click Configure from the Communication menu. When the dialog box opens, click Configure.
  2. In the Customize Communication panel, choose the appropriate Type of Host, Interface, and Attachment values for the desired Telnet host.
  3. Click Link Parameters.
  4. On the Host Definition property page, do the following:
    1. Specify the normal host name and LU parameters under Primary.
    2. Specify the Port Number under Primary. It is likely that it will not be the default port value for Telnet. The administrator of the destination server might have set up a specific port number to handle TLS/SSL service.
  5. On the Security Setup property page, check Enable Security.

    For server authentication only, no additional setup is required. For client authentication, proceed to the next step.

  6. For 3270 sessions, select the Telnet-negotiated option to have Z and I Emulator for Windows negotiate security with the Telnet 3270 server. See Negotiated Telnet Security for details. If Enable Security is unchecked, the Telnet-negotiated option cannot be selected.
  7. On the Security Setup property page, select the Microsoft CryptoAPI (MSCAPI) security package.
    Note:
    To avoid the need of manually adding host certificate into the Microsoft Certificate Store, refer to Pass Through Certificate Validation.
  8. To protect against security vulnerability in RC4 stream cipher, the FIPS (Federal Information Processing Standard) mode has been made mandatory.

    For MSCAPI, refer to the vedor documentation for the latest information.

    Note:
    Follow the below steps to enable AES support with MSCAPI on Windows 8, Windows 8.1, Windows 10, Windows Server 2008, and Windows Server 2012.
    1. From an administrator account, open Group Policy Editor (gpedit.msc).
    2. Choose Computer Configuration->Administrative Templates->Network->SSL Configuration Settings.
    3. Open SSL Cipher Suite Order and select Enabled.
    4. Alter the cipher order as per you organization's needs, save the changes, and REBOOT the system for the above changes to apply.
    It is important to note that the client can only present the server a prioritized cipher list. The host has the final say on what gets selected as the cipher for the session. When choosing an algorithm with a specific a bit length, one important consideration is to remember that encryption and decryption are CPU intensive operations which take time depending upon the key size. In almost all cases, a 128-bit key is more than sufficient to protect the information you are exchanging over your telnet connections.
  9. Enable Check for Server Name and Certificate Name Match to have the session authenticate the server by matching the server name to the host or server certificate name. The server and certificate names must match exactly. For MSCAPI sessions, if the certificate name and server name do not match, an error is returned.
  10. In the Client Authentication group box, you determine when and how the client certificate will be chosen for sending to the server.

    If you want to enable client authentication and have the personal client certificate from the key database file sent to the server when requested, check Send Personal Certificate to Server if Requested.

    Send Personal Certificate Trusted by Server
    Select this option if you do not want to be prompted to select a personal client certificate from a key database file. Z and I Emulator for Windows will send the personal client certificate trusted by the server.
    Send Personal Certificate based on Key Usage
    Use this option to select one or more key usages. Click Key Usage to select the defined Object ID (OID) key usages. Go to the Extended Key Usage panel to add a new OID and description to the list.

    At authentication time, Z and I Emulator for Windows chooses certificates for client authentication, based on the key usage that you select. If a certificate's Enhanced Key Usage attribute contains one or more of the OIDs that you specify, the certificate is eligible for use.

    If no eligible certificates are found, the authentication fails. If one eligible certificate is found, it is automatically used. If two or more eligible certificates are found, you will be prompted to select a personal client certificate.

    Select or Prompt for Personal Client Certificate
    Use this option if you want to choose the personal client certificate. You will be prompted to select a personal client certificate during session establishment, when the server requests the client certificate.

    To preselect a personal client certificate during configuration, click Select now and choose the Personal Certificate Label.

    Pass Through Host Certificate Validation
    Use this option to disable the default certificate validation process during TLS handshake. Applicable only for Microsoft schannel provider.
    Note:
    By default, schannel (MSCAPI) is responsible for validating the host certificate chain received during TLS handshake. Schannel runs several checks on the received certificate chain one of which is verifying that the signature affixed to the certificate valid, that is, the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer. In order to perform this operation, the user must possess the public component of the iss either through some integrity-assured channel, or by extracting it from another (validated) certificate. The default certificate valid process is exhaustive and runs several checks on the host certificate chain in order to successfully validate it. By enabling this option the user would effectively suppress the default validation done by schannel and the identity of the host is not verified. The use of this option is not recommended.

Problem Determination

Following is some information to help you avoid problems that might be related to TLS configuration.

Note:
Notify your server administrator of any problems prior to contacting HCL Service.

Using Transport Layer Security

Z and I Emulator for Windows allows you to negotiate the Transport Layer Security 1.0 protocol. The TLS protocol is based on the SSL protocol. TLS differs from SSL mainly in the initial handshake protocol for establishing client/server authentication and encryption. TLS also allows you to use FIPS (Federal Information Processing Standard) mode. Although TLS and SSL do not operate with each other, TLS provides a mechanism by which a TLS 1.0 implementation can revert to SSLv3.

The TLS protocol uses public-key and symmetric-key cryptographic technology. Public-key cryptography uses a pair of keys, one public and one private. Information encrypted with one key can only be decrypted with the other key. For example, information encrypted with the public key can be decrypted only with the private key. Each server's public key is published, while the private key is confidential. To send a secure message to the server, the client encrypts the message by using the server's public key. When the server receives the message, it decrypts the message with its private key.

Symmetric-key cryptography uses the same key to encrypt and decrypt messages. The client randomly generates a symmetric key to be used for encrypting all session data. The key is then encrypted with the server's public key and sent to the server.

TLS provides three basic security services:

Message privacy
Achieved through a combination of public-key and symmetric-key encryption. All traffic between a client and a server is encrypted using a key and an encryption algorithm negotiated during session setup.
Message integrity
Ensures that session traffic does not change while in route to its final destination. TLS and SSL use a combination of public/private keys and hash functions to ensure message integrity.
Mutual authentication
Exchange of identification through public-key certificates. The client and server identities are encoded in public-key certificates, which contain the following components:

Negotiated Telnet Security

Typically, a secure channel is established before the Telnet 3270 server and client negotiate for a session. For Z and I Emulator for Windows 3270 sessions, you can use negotiated Telnet security. This option enables Z and I Emulator for Windows to establish security with the Telnet 3270 server during the Telnet negotiation. The security protocol used is TLS 1.0, TLS 1.1, and TLS 1.2.

If you select the Telnet-negotiated option on the Security Setup panel, the Telnet connection is established. Z and I Emulator for Windows then uses the TLS-based Telnet Security protocol (as defined by IETF) to negotiate the TLS security. If the connection is successful, a status message is returned.

This support is only applicable with a Telnet server which supports the TLS-based Telnet Security protocol. By default, this option is not enabled.