In this article:
- Connecting through a proxy server
- Connecting with the Citrix Secure Web Gateway or Citrix Secure Sockets Layer Relay
- Connecting through Citrix Gateway
- Configuring deprecated cipher suites
To secure the communication between your server farm and Citrix Workspace app, you can integrate your Citrix Workspace app connections to the server farm with a range of security technologies, including:
- A SOCKS proxy server or secure proxy server (also known as security proxy server, HTTPS proxy server, or TLS tunneling proxy server). You can use proxy servers to limit access to and from your network and to handle connections between Citrix Workspace app and servers. Citrix Workspace app supports SOCKS and secure proxy protocols.
- Citrix Secure Web Gateway or SSL Relay solutions with Transport Layer Security (TLS) protocols. TLS versions 1.0 through 1.2 are supported.
- A firewall. Network firewalls can allow or block packets based on the destination address and port. If you are using Citrix Workspace app through a network firewall that maps the server’s internal network IP address to an external Internet address (that is, network address translation, or NAT), configure the external address.
Connecting through a proxy server
Proxy servers are used to limit access to and from your network, and to handle connections between Citrix Workspace app and your Citrix Virtual Apps or Citrix Virtual Desktops deployment. Citrix Workspace app supports the SOCKS protocol, along with the Citrix Secure Web Gateway and Citrix SSL Relay, the secure proxy protocol, and Windows NT Challenge/Response (NTLM) authentication.
The list of supported proxy types is restricted by the contents of Trusted_Regions.ini and Untrusted_Regions.ini to the Auto, None, and Wpad types. If you use the SOCKS, Secure or Script types, edit those files to add the additional types to the permitted list.
To ensure a secure connection, enable TLS.
Connecting through a secure proxy server
Configuring connections to use the secure proxy protocol also enables support for Windows NT Challenge/Response (NTLM) authentication. If this protocol is available, it is detected and used at run time without any additional configuration.
NTLM support requires that the OpenSSL library, libcrypto.so, is installed on the user device. This library is often included in Linux distributions, but can be downloaded from http://www.openssl.org/ if necessary in new window.
Connecting with the Citrix Secure Web Gateway or Citrix Secure Sockets Layer Relay
You can integrate Citrix Workspace app with the Citrix Secure Web Gateway or Secure Sockets Layer (SSL) Relay service. Citrix Workspace app supports the TLS protocol. TLS (Transport Layer Security) is the latest, standardized version of the SSL protocol. The Internet Engineering Taskforce (IETF) renamed it TLS when it took over responsibility for the development of SSL as an open standard. TLS secures data communications by providing server authentication, encryption of the data stream, and message integrity checks. Some organizations, including U.S. government organizations, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography, such as FIPS 140 (Federal Information Processing Standard). FIPS 140 is a standard for cryptography.
Connecting with the Citrix Secure Web Gateway
You can use the Citrix Secure Web Gateway in either Normal mode or Relay mode to provide a secure channel for communication between Citrix Workspace app and the server. No configuration of Citrix Workspace app is required if you are using the Citrix Secure Web Gateway in Normal mode and users are connecting through the Web Interface.
Citrix Workspace app uses settings that are configured remotely on the server running the Web Interface to connect to servers running the Citrix Secure Web Gateway. For information about configuring proxy server settings for Citrix Workspace app, see the Web Interface documentation.
If the Citrix Secure Web Gateway Proxy is installed on a server in the secure network, you can use the Citrix Secure Web Gateway Proxy in Relay mode. For more information, see the Citrix Virtual Apps (Citrix Secure Web Gateway) documentation.
If you are using Relay mode, the Citrix Secure Web Gateway server functions as a proxy and you must configure Citrix Workspace app to use:
- The fully qualified domain name (FQDN) of the Citrix Secure Web Gateway server.
- The port number of the Citrix Secure Web Gateway server. Relay mode is not supported by Citrix Secure Web Gateway Version 2.0.
The FQDN must list, in sequence, the following three components:
- Host name
- Intermediate domain
- Top-level domain
For example: my_computer.my_company.com is an FQDN, because it lists, in sequence, a host name (my_computer), an intermediate domain (my_company), and a top-level domain (com). The combination of intermediate and top-level domain (my_company.com) is referred to as the domain name.
Connecting with Citrix SSL Relay
By default, Citrix SSL Relay uses TCP port 443 on the Citrix Virtual Apps server for TLS-secured communication. When the SSL Relay receives a TLS connection, it decrypts the data before redirecting it to the server.
If you configure SSL Relay to listen on a port other than 443, you must specify the non-standard listening port number to Citrix Workspace app.
You can use Citrix SSL Relay to secure communications:
- Between a TLS-enabled user device and a server
- With Web Interface, between the Citrix Virtual Apps server and the web server
For information about configuring and using SSL Relay to secure your installation, see the Citrix Virtual Apps documentation. For information about configuring the Web Interface to use TLS encryption, see the Web Interface documentation.
Configuring and enabling TLS
You can control the versions of the TLS protocol that can be negotiated by adding the following configuration options in the [WFClient] section:
These values are the default values, which are implemented in code. Adjust them as you require.
Note: These values are read whenever programs start. If you change them after starting selfservice or storebrowse, type: killall AuthManagerDaemon ServiceRecord selfservice storebrowse.
Note: Citrix Workspace app for Linux does not allow the use of the SSLv3 protocol.
Citrix Workspace app for Linux supports DTLS 1.0 and TLS 1.0, 1.1 and 1.2, with the following cipher suites:
- RSA+AES256-SHA (RSA for key exchange, AES 256 for encryption, SHA-1 for digest)
- RSA+AES256-SHA256 (RSA for key exchange, AES 256 for encryption, SHA-256 for digest)
- RSA+AES128-SHA (RSA for key exchange, AES 128 for encryption, SHA-1 for digest)
- RSA+DES-CBC3-SHA (RSA for key exchange, Triple-DES for encryption, SHA-1 for digest)
- RSA+RC4128-MD5 (RSA for key exchange, RC4 128 for encryption, MD5 for digest)
- RSA+RC4128-SHA (RSA for key exchange, RC4 128 for encryption, SHA-1 for digest)
- RSA+AES128_GCM+SHA256 (RSA for key exchange, AES 128 for encryption, SHA-256 for digest)
- RSA+AES256_GCM+SHA384 (RSA for key exchange, AES 256 for encryption, SHA-384 for digest)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Elliptic curve Diffie–Hellman for key exchange, RSA for authentication, AES 256, and GCM SHA 384 for digest)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Elliptic curve Diffie–Hellman for key exchange, RSA for authentication, AES 256, and CBC SHA 384 for digest)
- TLS_RSA_AES256_CBC_SHA256 (RSA for authentication, AES 256, and CBC SHA 256 for digest)
The effective encryption key size is as defined for that standard SSL/TLS cipher suite as named above:
- RC4 algorithm: 128 bits (stream cipher)
- Triple DES algorithm: 3x64 bits (effective size 3x56=168 bits) (block size 64 bits)
- AES algorithm: 128 bits or 256 bits (block size 128)
- For RSA key exchange and authentication the supported key lengths (modulus) range from 1,024 bits to 4,096 bits.
- For ECDH key exchange, the supported elliptic curves are NIST P-256 and NIST P-384 (256 bit and 384 bit key lengths).
To select the cipher suite set, add the following configuration option in the [WFClient] section:
This value is the default value. Other recognized values are COM and ALL. Note: As with the TLS version configuration, if you change this after starting selfservice or storebrowse you must type: killall AuthManagerDaemon ServiceRecord selfservice storebrowse
Installing root certificates on user devices
To use TLS, you need a root certificate on the user device that can verify the signature of the Certificate Authority on the server certificate. By default, Citrix Workspace app supports the following certificates.
|Class4PCA_G2_v2.pem||VeriSign Trust Network|
|Class3PCA_G2_v2.pem||VeriSign Trust Network|
|BTCTRoot.pem||Baltimore Cyber Trust Root|
|GTECTGlobalRoot.pem||GTE Cyber Trust Global Root|
|Pcs3ss_v4.pem||Class 3 Public Primary Certification Authority|
|DigiCertGlobalRootCA.pem||DigiCert Global Root CA|
You are not required to obtain and install root certificates on the user device to use the certificates from these Certificate Authorities. However, if you choose to use a different Certificate Authority, you must obtain and install a root certificate from the Certificate Authority on each user device.
Citrix Workspace app for Linux supports RSA keys of 1024, 2048, and 3072-bit lengths. Root certificates with RSA keys of 4096-bit length are also supported.
Note: Citrix Workspace app for Linux 1808 and above uses the ctx_rehash tool as described in the following steps.
Use a root certificate
If you authenticate a server certificate that was issued by a certificate authority and is not yet trusted by the user device, follow these instructions before adding a StoreFront store.
- Obtain the root certificate in PEM format. Tip: If you cannot find a certificate in this format, use the openssl utility to convert a certificate in CRT format to a .pem file.
- As the user who installed the package (usually root):
Copy the file to $ICAROOT/keystore/cacerts.
Run the following command:
pre codeblock $ICAROOT/util/ctx_rehash
Use an intermediate certificate
If your StoreFront server is not able to provide the intermediate certificates that match the certificate it is using, or you install intermediate certificates to support smart card users, follow these steps before adding a StoreFront store.
- Obtain one or more intermediate certificates separately in PEM format. Tip: If you cannot find a certificate in this format, use the openssl utility to convert a certificate in CRT format to a .pem file.
- As the user who installed the package (usually root):
Copy one or more files to $ICAROOT/keystore/intcerts.
Run the following command as the user who installed the package:
pre codeblock $ICAROOT/util/ctx_rehash
Enabling smart card support
Citrix Workspace app for Linux supports various smart card readers. If smart card support is enabled for both the server and Citrix Workspace app, you can use smart cards for the following purposes:
- Smart card logon authentication. Use smart cards to authenticate users to Citrix Virtual Apps servers.
- Smart card application support. Enable smart card-aware published applications to access local smart card devices.
Smart card data is security sensitive and should be transmitted over a secure authenticated channel, such as TLS.
Smart card support has the following prerequisites:
- Your smart card readers and published applications must be PC/SC industry standard compliant.
- Install the appropriate driver for your smart card.
- Install the PC/SC Lite package.
- Install and run the pcscd Daemon, which provides middleware to access the smart card using PC/SC.
- On a 64-bit system, both 64-bit and 32-bit versions of the “libpscslite1” package must be present.
Important: If you are using the SunRay terminal with SunRay server software Version 2.0 or later, install the PC/SC SRCOM bypass package, available for download from http://www.sun.com/.
For more information about configuring smart card support on your servers, see the Citrix Virtual Apps and Desktops documentation.
Connecting through Citrix Gateway
Citrix Gateway (formerly Access Gateway) secures connections to StoreFront stores, and lets administrators control, in a detailed way, user access to desktops and applications.
To connect to desktops and applications through Citrix Gateway
Specify the Citrix Gateway URL that your administrator provides. You can do this in one of these ways:
- The first time you use the self-service user interface, you are prompted to enter the URL in the Add Account dialog box
- When you later use the self-service user interface, enter the URL by clicking Preferences > Accounts > Add
- If you are establishing a connection with the storebrowse command, enter the URL at the command line
The URL specifies the gateway and, optionally, a specific store:
- To connect to the first store that Citrix Workspace app finds, use a URL of the form, for example: https://gateway.company.com.
- To connect to a specific store, use a URL of the form, for example: https://gateway.company.com?<storename>. This dynamic URL is in a non-standard form; do not include = (the equals sign character) in the URL. If you are establishing a connection to a specific store with storebrowse, you might need quotation marks around the URL in the storebrowse command.
When prompted, connect to the store (through the gateway) using your user name, password, and security token. For more information on this step, see the Citrix Gateway documentation.
When authentication is complete, your desktops and applications are displayed.
Configuring deprecated cipher suites
Cipher suites with the prefix TLS_RSA_ do not offer forward secrecy. These cipher suites are now generally deprecated by the industry. However, to support backward compatibility with older versions of Citrix Virtual Apps and Desktops, Citrix Workspace app for Linux has an option to enable these cipher suites.
Flags have been created to allow the usage of deprecated cipher suites. In Citrix Workspace app 1808 for Linux version, these flags are enabled by default, but they do not enforce deprecation for the cipher suites using the AES or 3DES algorithms by default. However, you can modify and use these flags to enforce the deprecation more strictly.
For better security, set the flag Enable_TLS_RSA_ to False.
Following is the list of deprecated cipher suites:
The last two cipher suites use the RC4 algorithm and are deprecated because they are insecure. You might also consider the TLS_RSA_3DES_CBC_EDE_SHA cipher suite to be deprecated. You can use flags to enforce all these deprecations.
For information on configuring DTLS v1.2, see Adaptive transport.
To configure this feature on client, perform the following step:
If .ICAClient is already present in the home folder of the current user:
- Delete All_Regions.ini file
- To retain AllRegions.ini file, add the following lines at the end of the [Network\SSL] section:
If the .ICAClient folder is not present in the home folder of the current user, then it indicates a fresh install of the Citrix Workspace app. In that case, the default setting for the features is retained.
To configure deprecated cipher suites
- Open the $ICAROOT/config/All_Regions.ini file.
Under the Network\SSL section, use the following three flags to enable or disable the deprecated cipher suites:
Enable_TLS_RSA_: By default, the flag Enable_TLS_RSA_ is set to True. Set the flag Enable_TLS_RSA_ to true to view the following cipher suites:
Set the flag Enable_TLS_RSA_ to true to use the other two cipher suites Enable_RC4-MD5 and Enable_RC4_128_SHA.
- Enable_RC4-MD5: By default, the flag Enable_RC4-MD5 is set to False. Set this flag to true to enable the RC4-MD5 cipher suite.
- Enable_RC4_128_SHA: By default, the flag Enable_RC4_128_SHA is set to False. Set this flag to true to enable the RC4_128_SHA cipher suite.
- Save the file.
The following table lists the cipher suites in each set:
Table 1 – Cipher suite support matrix
In the future, Citrix will be supporting only the following three cipher suites:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 – TLS 1.2/DTLS 1.2, GOV/ALL
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 – TLS 1.2/DTLS 1.2 GOV/ALL
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA – TLS 1.0/1.1/1.2, DTLS 1.0/1.2 COM/ALL
All cipher suites above are FIPS- and SP800-52- compliant. The first two are allowed only for (D)TLS1.2 connections. See Table 1 – Cipher suite support matrix for a comprehensive representation of cipher suite supportability.