Overview of SSL Support in the N1 Grid Service Provisioning System 5.0

SSL is a protocol for securing communication over IP networks. SSL uses TCP/IP sockets technology to exchange messages between a client and a server, while protecting the message with a public and private key encryption system developed by RSA. Support for SSL is included in most web server products, as well as in the Netscape Navigator and Microsoft web browsers.

N1 Grid Service Provisioning System 5.0 applications can be configured to use SSL for their network communications, preventing messages from being read or tampered with. Optionally, applications can be configured to use SSL to authenticate before communicating, further increasing network security.

Cipher Suites: Encryption and Authentication Overview

The SSL protocol supports a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. The cipher suite that SSL uses to connect determines whether any authentication takes place.

Exercise caution when selecting cipher suites. Each application must enable only those cipher suites that provide the minimum security needed by the node. SSL uses the most secure cipher suites supported by both the client and server. If low security cipher suites are enabled, a third party client can force the server to use the less secure cipher suites by publishing support for only the least secure cipher suite during cipher suite negotiation.

SSL can be operated in the following modes:

• Encryption only, no authentication – Connections are encrypted. However, SSL does not authenticate the applications that are connecting.

• Server Authentication – Clients authenticate the server to which they are connecting.

• Server and Client Authentication – Both the client and server authenticate each other.

During the installation, when you select to use SSL to secure communications between applications, you are prompted to select the cipher suite to use. The cipher suite value is stored as the value of net.ssl.cipher.suites in the config.properties file. The cipher suite value is set to the following value based on the selection you make:

• If you select encryption, no authentication, the cipher suite is set to SSL_DH_anon_WITH_3DES_EDE_CBC_SHA.

• If you select encryption, with authentication, the cipher suite is set to SSL_RSA_WITH_3DES_EDE_CBC_SHA.

When you use SSL with a Local Distributor on an AIX server, the SSL cipher suite is set to encryption with authentication. Encryption with no authentication is not available for Local Distributors that are running on AIX servers.

For lists of SSL cipher suites that do and do not require server authentication, see SSL Cipher Suites. You can configure client authentication only for cipher suites that require server authentication.

The N1 Grid Service Provisioning System 5.0 applications allow you to configure SSL connections with encryption, no authentication or encryption with authentication. Encryption with authentication uses client and server authentication. Although the configurations described above are possible, encryption, with authentication is the most secure.

Authentication Keystores

The N1 Grid Service Provisioning System 5.0 supports self-signed certificates and certificates signed by a Certifying Authority. Two types of keystores exist:

• Private Keystore – The private keystore contains the public-private key pairs that the application uses to authenticate itself when connecting to other applications.

• Trust Keystore – The trust keystore contains the public key, in self-signed certificates, of other applications that the keystore trusts and allows them to connect to the application.

When enabling SSL for client-server authentication, each enabled application needs to be configured with two keystores that SSL will use to authenticate itself to other applications and to authenticate other applications.

When enabling SSL for server-only authentication, the application acting as the SSL server requires a private keystore and the application acting as the SSL client requires a public, or trusted, keystore. The public keystores are in the proprietary JKS format provided by the Java Secure Sockets Extension (JSSE) v1.0.3.

You must specify a password for both of the keystores. The password for both of the keystores must be the same.

For example, application A, an SSL client, and application B, an SSL server, want to connect with each other using SSL. Both are configured to use a cipher suite that requires server authentication. Application B must have a public-private key pair in its private keystore, and application A must have application B's public key in its trust keystore. When application A attempts to connect to application B, application B sends its public key down to application A. Application A is able to verify the public key by finding it in its trust keystore.

If application B is configured to require client authentication, application A must have a public-private key pair in its private keystore. Also,application B must have application A's public key in its trust keystore. After application A has authenticated application B, application B is able to verify application A's public key, as it finds the public key in its trust keystore.

Using Passwords With SSL

If you supply a password for trust keystore operations, the password is only used to verify the integrity of the keystore. The password does not prevent access to the contents of the trust keystore, but it does protect updates to the keystore. Users are not able to change the contents of the keystore without supplying the password.

If you supply a password for private keystore operations, the password is used to verify the integrity of the keystore, protect against modifications of the keystore contents, and to encrypt and protect access to the private key.

The crkeys script validates that you specified the same password for both the keystores. When creating a trust store for the first time by importing certificates, the crkeys script ensures that the trust store has the same password as the private store, if one exists. Similarly, when creating a private store for the first time, the crkeys script ensures that the private store has the same password as the trust store, if one exists.

Limitations of SSL on the N1 Grid Service Provisioning System 5.0

The SSL implementation on the N1 Grid Service Provisioning System 5.0 has the following limitations:

• Both the trust and the private keystores must be configured with the same password. Also, within the private keystore, the key password for each key in the store must be the same as the store password. The crkeys script used to create keys enforces this limitation.

• Although enabling client authentication for CLI Client applications is possible, this setup is not supported due to security limitations. The CLI Client applications do not prompt the user for keystore passwords. If the keystores have been created, the keystores must be provided in the CLI Client properties file.

• The N1 Grid Service Provisioning System 5.0 uses single trust keystore for both incoming and outgoing connections. Therefore, if a Master Server connects to a Remote Agent and trusts its public key and if that Remote Agent becomes compromised, that Remote Agent's keys could be used to authenticate the CLI Client to the Master Server, if the CLI Client were to use client authentication. Similarly, if a Local Distributor connects to a Remote Agent and the Remote Agent becomes compromised, the Local Distributor can be used to issue commands to the Master Server.

  To secure the Master Server and the Local Distributor against such issues, configure the applications to accept connections only from servers that are expected to connect to them. Permit a Local Distributor to accept connections only from its parent node. Permit the Master Server to accept connections only from the designated CLI hosts. For instructions, see Chapter 8, Configuring the Java Virtual Machine Security Policy.

• For SSH connections, the remote application, the Local Distributor or Remote Agent, is automatically started. The server does not prompt you for the keystore passwords to start these applications. If the applications are initialized with keystores, the passwords to their keystores must be specified in their properties file.

• When you configure the CLI Client to connect to the Master Server using SSH, the CLI Client connects to the Master Server using an SshProxy application that connects to the Master Server through sockets. The SshProxy can connect to the Master Server through SSL, but this configuration is not supported.