Tuning Secure Connections to SGD Servers

This section describes the tuning that can be applied to secure connections to SGD servers and includes the following topics:

• Tuning the SSL Daemon

• Using External SSL Accelerators

• Selecting a Cipher Suite for Secure Connections

• Using Connection Definitions

Tuning the SSL Daemon

The SSL Daemon is the SGD component that handles secure connections to SGD servers. On the SGD host, the SSL Daemon is listed as one or more ttassl processes.

By default, the SSL Daemon listens on TCP port 5307 for AIP traffic that has been encrypted with SSL. However, if you are using firewall forwarding, the SSL Daemon listens on port 443, and accepts AIP and HTTPS traffic. In this situation, the Daemon handles the AIP traffic but forwards the HTTPS traffic on to the SGD web server.

Sometimes the load on the SSL Daemon can affect performance. If you have a multi-processor server, you can tune the number of SSL Daemon processes to the number of processors to improve performance. SSL Daemon tuning is specific to each SGD server. By default, SGD starts four SSL Daemon processes. See How to Tune SSL Daemon Processes for detail of how to change the number of SSL Daemon processes.

You can use log filters to monitor SSL Daemon processes. By default, all errors are logged. You can increase the amount of log output to assist with tuning or for troubleshooting, see How to Change SSL Daemon Log Filters. The log filters you use have the same format as the log filters used for the SGD server. See Using Log Filters to Troubleshoot Problems With an SGD Server. The same severity and destination file options can be used. By default, all errors are logged to the /opt/tarantella/var/log directory.

If the SSL Daemon exits unexpectedly, it makes 10 attempts to restart before failing completely. You can change the maximum number of restart attempts, see How to Change SSL Daemon Maximum Restart Attempts.

How to Tune SSL Daemon Processes

Before You Begin

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

1. Log in to the SGD host as superuser (root).

2. Change the number of SSL Daemon processes.

   Use the following command:

   # tarantella config edit \
   --tarantella-config-ssldaemon-minprocesses num \
   --tarantella-config-ssldaemon-maxprocesses num

   The default num is 4.

   Use the same value for the minimum and maximum processes.

   You tune SSL Daemon processes for the number of processors and not for the number of processor cores. Configure no more than one SSL daemon for each processor.

3. Restart the SGD server.

   You must restart the SGD server for the change to take effect.

How to Change SSL Daemon Log Filters

Before You Begin

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

1. Log in to the SGD host as superuser (root).

2. Change the SSL Daemon log filters.

   Use the following command:

   # tarantella config edit \
   --tarantella-config-ssldaemon-logfilter filter ...

   Use a comma-separated list of filters.

   The default filters are:

   ssldaemon/*/*error,multi/daemon/*error:sslmulti%%PID%%.log

3. Restart the SGD server.

   You must restart the SGD server for the change to take effect.

How to Change SSL Daemon Maximum Restart Attempts

Before You Begin

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

1. Log in to the SGD host as superuser (root).

2. Change the maximum number of SSL Daemon restart attempts.

   Use the following command:

   # tarantella config edit \
   --tarantella-config-ssldaemon-maxrestarts num

   The default maximum number is 10. Setting the number of restart attempts to -1 means there is no limit on the number of restart attempts.

3. Restart the SGD server.

   You must restart the SGD server for the change to take effect.

Using External SSL Accelerators

SGD supports the use of external SSL accelerators. Performance can be improved by off-loading the processor-intensive transactions required for SSL connections to an external SSL accelerator. External SSL accelerators can also be used to centralize server SSL certificates.

The information in this section applies when an SSL accelerator is used for connections to SGD servers. The Oracle Secure Global Desktop 4.6 Gateway Administration Guide has details of how to use SSL accelerators with the SGD Gateway.

To use an external SSL accelerator with SGD, do the following:

• Install the SSL certificate for each SGD server in the array on the external SSL accelerator

• Configure the external SSL accelerator to decrypt SSL connections and forward them as unencrypted connections to SGD

• Enable external SSL accelerator support in SGD

When you enable external SSL accelerator support, the SGD SSL Daemon can accept plain text traffic on the port configured for secure connections, and forward it to SGD as SSL traffic it had decrypted itself.

If you are using server-side proxy servers, you might have to configure your array routes for external SSL accelerators. See Configuring Server-Side Proxy Servers.

How to Enable External SSL Accelerator Support

Before You Begin

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

1. In the Administration Console, go the Secure Global Desktop Servers tab and select an SGD server.

2. Go to the Security tab.

3. Select the SSL Accelerator Support check box.

4. Click Save.

5. Restart the SGD server.

   You must restart the SGD server for the change to take effect.

Selecting a Cipher Suite for Secure Connections

You can select the cipher suite that is used for secure connections to SGD servers, see How to Change the Cipher Suite for Secure Client Connections for details.

A cipher suite is a set of cryptographic algorithms used for the following:

• Key exchange – Protects the information required to create shared keys

• Bulk encryption – Encrypts messages exchanged between clients and servers

• Message authentication – Generates message hashes and signatures to ensure the integrity of a message

A cipher suite specifies one algorithm for each of these tasks. For example, the RSA_WITH_RC4_128_MD5 cipher suite uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message authentication.

Supported Cipher Suites for Secure Client Connections lists the supported cipher suites.

Supported Cipher Suites for Secure Client Connections

Supported Cipher Suite Client Preference OpenSSL Name RSA_WITH_AES_256_CBC_SHA 1 AES256-SHA RSA_WITH_AES_128_CBC_SHA 2 AES128-SHA RSA_WITH_3DES_EDE_CBC_SHA 3 DES-CBC3-SHA RSA_WITH_RC4_128_SHA 4 RC4-SHA RSA_WITH_RC4_128_MD5 5 RC4-MD5 RSA_WITH_DES_CBC_SHA 6 DES-CBC-SHA

When selecting a cipher suite, you use the OpenSSL Name of the cipher suite, as shown in Supported Cipher Suites for Secure Client Connections. If you select more than one cipher suite, the SGD Client determines which suite is used, based on the client preference order shown in the table above.

By default, the SGD Client uses the RSA_WITH_AES_256_CBC_SHA cipher suite.

How to Change the Cipher Suite for Secure Client Connections

Before You Begin

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

1. Log in as superuser (root) on the primary SGD server in the array.

2. Stop all the SGD servers in the array.

3. Specify the cipher suite.

   Use the following command:

   # tarantella config edit \
   --tarantella-config-security-ciphers cipher-suite ...

   where cipher-suite is the OpenSSL Name of a cipher suite as listed in Selecting a Cipher Suite for Secure Connections.

   If you specify more than one cipher-suite, use a colon-separated list.

   The default setting is AES256-SHA:RC4-MD5

4. Restart all the SGD servers in the array.

   You must restart the SGD servers for the change to take effect.

Using Connection Definitions

Connection definitions can be used to control whether a secure or a standard connection is used when connecting to an SGD server. The connection type can depend on the following factors:

• The DNS name or IP address of the user’s client device

• The SGD server the user logs in to

If SGD security services are not enabled on an SGD server, secure connections to that server are not available regardless of the user’s connection definitions.

If you use the SGD Gateway, connection definitions are only used for direct client connections that are not routed through an SGD Gateway.

To use connection definitions, you must do the following:

• Enable connection definition processing – See How to Enable Connection Definition Processing

• Configure connection definitions – See How to Configure Connection Definitions

When connection definition processing is enabled, you configure the connection definitions to determine which users receive standard or secure connections. You configure connection definitions at an organization level, which you can override at an organizational unit level or user profile level. By default, all users can receive secure connections if SGD security services are enabled.

Connection definitions use the IP address or DNS name of the client device and the SGD server to determine whether standard or secure connections are used. The order of the connection definitions is important as the first match is used. Connection definitions can include the * or ? wildcards to match more than one DNS name or IP address.

For example, the user profile object for Elizabeth Blue has the following connection definitions:

Client Device Address SGD Server Address Connection Type *.example.com * Standard * * Secure

If Elizabeth logs in to SGD from her usual client device, sales1.example.com, the first connection definition in the list matches and Elizabeth receives a standard connection.

If Elizabeth logs in to SGD from a client device that is not part of example.com, the second connection definition in the list matches and Elizabeth receives a secure connection.

If Elizabeth had no connection definitions, the connection type is determined by the connection definitions of a parent object in the organizational hierarchy.

How to Enable Connection Definition Processing

1. In the Administration Console, go to the Global Settings -> Security tab.

2. Select the Connection Definitions check box.

3. Click Save.

How to Configure Connection Definitions

1. In the Administration Console, go to the User Profiles tab and select the object you want to configure.

   It is best to configure connection definitions for organization and organizational unit objects as this configures connections definitions for many users at once and makes administration easier.

2. Go to the Security tab.

3. Add a connection definition.

   DNS names or IP addresses in a connection definition can include the * or ? wildcards.

   1. In the Connection Definitions table, click the Add button.

      The Add New Connection Definition window is displayed.

   2. In the Client Device Address field, type an IP address or DNS name.

   3. In the Secure Global Desktop Server Address, type an IP address or DNS name.

   4. Select a Connection Type from the list.

   5. Click Add.

      The Add New Connection Definition window closes and the connection definition is added to the Connection Definitions table.

4. Add further connection definitions as needed.

   The Connection Definitions table also shows the definitions that are inherited from parent objects in the organizational hierarchy.

5. Use the Move Up and Move Down buttons to change the order of the connection definitions.

   The order of the connection definitions is important. The first matching entry is used. Make sure the most specific definitions appear before more general ones.