This section describes the tuning that can be applied to secure connections to SGD servers and includes the following topics:
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 Section 1.6.1.1, “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
Section 1.6.1.2, “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
Section 7.4.3, “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 Section 1.6.1.3, “How to Change SSL Daemon Maximum Restart Attempts”.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
Log in to the SGD host as superuser (root).
Change the number of SSL Daemon processes.
Use the following command:
# tarantella config edit \ --tarantella-config-ssldaemon-minprocessesnum
\ --tarantella-config-ssldaemon-maxprocessesnum
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.
Restart the SGD server.
You must restart the SGD server for the change to take effect.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
Log in to the SGD host as superuser (root).
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
Restart the SGD server.
You must restart the SGD server for the change to take effect.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
Log in to the SGD host as superuser (root).
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.
Restart the SGD server.
You must restart the SGD server for the change to take effect.
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 Gateway Administration Guide for Release 4.7 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 Section 1.3.4, “Configuring Server-Side Proxy Servers”.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
In the Administration Console, go the Secure Global Desktop Servers tab and select an SGD server.
Go to the Security tab.
Select the SSL Accelerator Support check box.
Click Save.
Restart the SGD server.
You must restart the SGD server for the change to take effect.
You can select the cipher suite that is used for secure connections to SGD servers, see Section 1.6.3.1, “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.
Table 1.1, “Supported Cipher Suites for Secure Client Connections” lists the supported cipher suites.
Table 1.1. 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 Table 1.1, “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.
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.
Log in as superuser (root) on the primary SGD server in the array.
Stop all the SGD servers in the array.
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
Section 1.6.3, “Selecting a Cipher Suite for Secure Connections”.
The default setting is AES256-SHA
If you specify more than one
cipher-suite
, use a
colon-separated list.
Restart all the SGD servers in the array.
You must restart the SGD servers for the change to take effect.
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 SGD is configured for firewall forwarding, do not use connection definitions. You always use secure connections with firewall forwarding. See Section 1.5.2, “Firewall Traversal”.
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 Section 1.6.4.1, “How to Enable Connection Definition Processing”
Configure connection definitions – See Section 1.6.4.2, “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 |
---|---|---|
|
| 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.
In the Administration Console, go to the Global Settings → Security tab.
Select the Connection Definitions check box.
Click Save.
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.
Go to the Security tab.
Add a connection definition.
DNS names or IP addresses in a connection definition can
include the *
or ?
wildcards.
In the Connection Definitions table, click the Add button.
The Add New Connection Definition window is displayed.
In the Client Device Address field, type an IP address or DNS name.
In the Secure Global Desktop Server Address, type an IP address or DNS name.
Select a Connection Type from the list.
Click Add.
The Add New Connection Definition window closes and the connection definition is added to the Connection Definitions table.
Add further connection definitions as needed.
The Connection Definitions table also shows the definitions that are inherited from parent objects in the organizational hierarchy.
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.