Security

  • Updated on Nov 19, 2024
  • Published on Sep 17, 2024
  • 4 minute(s) read

HTTP Strict Transport Security (HSTS)

In v37 and later, you can force users’ browsers to connect to your instance via HTTPS rather than HTTP by enabling HSTS. 

Enabling HSTS adds the Strict-Transport-Security HTTP response header to your application URL’s responses. This header provides an additional layer of security for your instance by preventing cookie-hijacking and downgrade attacks, among other types of malicious activity.

Enabling and configuring HSTS

HSTS is disabled by default. To enable HSTS, add the following variable to your “.env” file:

HS_SECURE_HSTS_SECONDS=<value for max-age for the Strict-Transport-Security header>

This variable specifies the number of seconds that users’ browsers should remember the URL’s enforcement of HTTPS-only access.

You can further configure HSTS for your instance by adding the following optional variables to your “.env” file:

  • HS_SECURE_HSTS_INCLUDE_SUBDOMAINS — If set to true, includeSubDomains is added to the Strict-Transport-Security header, applying HSTS protections across all of the URL’s subdomains.

  • HS_SECURE_HSTS_PRELOAD — If set to true, preload is added to the Strict-Transport-Security header.

    • If this variable is set to true, HS_SECURE_HSTS_SECONDS must be greater than or equal to 31536000 (1 year), and HS_SECURE_HSTS_INCLUDE_SUBDOMAINS must be set to true.

For more information on HSTS, see Mozilla’s Strict-Transport-Security - HTTP.

Excluding X-Extract-Backend-Server HTTP headers

The X-Extract-Backend-Server HTTP header of each application response contains the hostname of the VM that processed the request. In v30.0.7+ and v31.0.1+, you can exclude these headers from your application’s responses. To do so, add the NGINX_DISABLE_BACKEND_SERVER_HEADER variable to your ".env" file and set its value to yes:

NGINX_DISABLE_BACKEND_SERVER_HEADER=yes

HTTP listening port

To set an HTTP listening port for inbound connections to the application, set the NGINX_PORT variable. By default, the system uses port 80. 

NGINX_PORT=<listening port number>

TLS / HTTPS

To enable TLS in the Hyperscience application, a certificate and a key must be provided.

Hyperscience expects PEM-formatted certificates. This page discusses how to convert DER-encoded certificates and Java Keystore (JKS) certificates to the PEM format.

First, create the directory that will hold the certificate and key. Assuming “/mnt/hs/” is used as the HS_PATH:

mkdir -p /mnt/hs/certs 

To learn more about sharing files (e.g., certificates) across application machines, see Best Practices for Sharing Files Across Machines.

Second, copy the certificate and key to this directory.

Third, if SELinux is enabled, execute:

chcon -t container_file_t -R /mnt/hs/certs/

If SELinux is enabled, each time a file is added to the certs directory above for any reason, the chcon command will need to be executed again.

TLS configuration for inbound connections

Add the following to the “.env” file:

NGINX_ENABLE_SSL=yes
NGINX_TLS_CERT=<cert filename (just filename without folder path)>
NGINX_TLS_KEY=<key filename (just filename without folder path)>
SECURE_COOKIES=true

In the parameters above,  and  are the names of the two files that were copied into the “/mnt/hs/certs” directory.

Optionally, an HTTP -> HTTPS redirect can be enabled in the “.env” file:

NGINX_ENABLE_SSL_REDIRECT=yes

To set a TLS port, use the NGINX_TLS_PORT variable. By default, the system uses port 443.

NGINX_TLS_PORT=<TLS port number>

TLS configuration for outbound connections

Depending on how the Hyperscience application is configured, it may connect to various external services, such as a UiPath Orchestrator instance, using the HTTPS or TLS protocol.

To give you flexibility in provisioning your TLS/SSL certificates, we have provided the two configuration settings described below. In v33 and later, these settings apply to connections that use Java Message Service (JMS), which include RabbitMQ, ActiveMQ, and IBM MQ output connections. They also apply to the connection between the trainer and the main application in all versions of Hyperscience.

Note that you can use only one of these two variables as they are mutually exclusive.

HS_TLS_VERIFY_ENABLED

This setting disables validation of certificates when establishing an HTTPS or TLS connection: 

HS_TLS_VERIFY_ENABLED=false

Doing so allows the use of self-signed certificates or enterprise-signed certificates.

HS_TLS_CA_BUNDLE

This setting specifies a custom bundle of CA certificates to validate against when establishing an HTTPS or TLS connection: 

HS_TLS_CA_BUNDLE=<CA_bundle_filename>

The filename used must be a file in the HS_PATH/certs directory. To give the application read access the CA bundle file, run the following command:

chmod 644 $HS_PATH/certs/*

If using SELinux, make sure to run:

chcon -t container_file_t .

This bundle will replace the default set of trusted CA certificates, so it must include all root certificates used by external services. To combine multiple certificates, simply concatenate them together into a single file.

Load balancer

To achieve HA/DR goals for the application, we encourage customers to deploy the application on multiple VMs and to use a load balancer for the web requests. To learn more about using a load balancer to distribute web requests, see Load Balancer.

  • Note: the application uses the HTTP_HOST from the request to generate some of its links. If you are configuring a Load Balancer, please bear this in mind.

Security Levels

By default, we only support TLS versions 1.2 and above. However, our OpenSSL library configuration options allow you to use TLS 1.0 or 1.1, if necessary.

OpenSSL configurations

The OpenSSL library is the default TLS protocol implementation in Linux. For compatibility reasons, we use a custom OpenSSL configuration to relax TLS cipher suite requirements. The following variables can be configured in the ".env" file, which allow you to fine-tune your TLS cipher suites:

HS_CUSTOM_OPENSSL_CNF_DISABLE=<yes/no, default is not set>
HS_OPENSSL_SECLEVEL=<sec level, default is 1>
HS_OPENSSL_MINPROTOCOL=<TLS version, default is TLSv1.2>

  • HS_CUSTOM_OPENSSL_CNF_DISABLE=yes – Note that yes disables the custom configuration in Hyperscience and restores the default OpenSSL cipher options. Any value other than yes enables the custom configuration in Hyperscience.

  • To learn more about HS_OPENSSL_SECLEVEL options and descriptions, see OpenSSL’s SSL_CTX_set_security_level documentation.

  • To learn more about HS_OPENSSL_MINPROTOCOL options, see the “-min_protocol, -max_protocol” section of OpenSSL’s SSL_CONF_cmd documentation.

To learn more about OpenSSL, see OpenSSL’s Documentation.

Logging NGINX-related issues

With the NGINX_ERROR_LOG_LEVEL ".env" file variable in v40 and later, you can specify the minimum severity level an issue must have in order for it to be logged by the syslog utility.

Possible values, from least severe to most severe, are:

  • debug

  • info (default)

  • notice

  • warn

  • error

  • crit

  • alert

  • emerg

You can choose the level that will help you debug NGINX-related issues most effectively. If you choose the default value of info, issues with info, notice, warn, error, crit, alert, and emerg severity levels will be logged.

For more details, see NGINX's Configuring Logging.