Overview of SSL Support in the Sun N1 Service Provisioning System 5.2

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.

Sun N1 Service Provisioning System 5.2 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 Sun N1 Service Provisioning System 5.2 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 Sun N1 Service Provisioning System 5.2 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.

When you generate a keystore using the crkeys command, you use the -mode upstream|downstream option to specify the location of the machine that is being authenticated in relationship to the machine that is performing the authentication. When attempting an SSL connection, the server that is validating the connection verifies that the certificate it received contains a mode that matches the relative location of the server that transmitted the certificate. For example, a Local Distributor receives an SSL connection request from a Master Server. The Local Distributor verifies that the Master Server certificate does not have a downstream annotation.

The server does not verify that a certificate contains an upstream annotation. The server only verifies that the certificate does not have a downstream annotation. Consequently, any servers that were originally configured to use SSL without an upstream annotation will continue to connect using SSL.

A CLI client cannot validate a connection with a server that transmits a certificate with an upstream annotation because no server can be upstream from a CLI client. A Remote Agent cannot validate a connection with a server that transmits a certificate with a downstream annotation because no server can be downstream from a Remote Agent.

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 command 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.

The crkeys command enables you to create an encoded version of the keystore password. You can use the encoded version of the password in any properties files in which you intend to save the keystore password. Saving an encoded version of the password in a properties file is more secure than saving the plaintext version of a password in a properties file.

Limitations of SSL on the Sun N1 Service Provisioning System 5.2

The SSL implementation on the Sun N1 Service Provisioning System 5.2 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 encoded password must be provided in the CLI Client properties file.

• The Sun N1 Service Provisioning System 5.2 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 9, 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 encoded 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.

• For windows applications, the encoded keystore password must be supplied in the properties file.