Encryption Between the Mobile Access Service and SafeLinx Clients

You can modify the type of encryption that is used to transmit data between SafeLinx Clients and the mobile access service.

HCL SafeLinx supports the Advanced Encryption Standard (AES) to encrypt data that is transmitted between the SafeLinx Client and the mobile access service. AES is a block cipher based on Federal Information Processing Standard (FIPS) 197 publication. You can configure the minimum level of encryption for a connection profile. Key strengths of 128, 192, or 256 are available. Under the default setting (0 - Optional), the SafeLinx Server does not enforce a minimum level. The current versions of the SafeLinx Client are configured so that they always propose 256-bit AES encryption. If you support earlier versions of the SafeLinx Client, which default to using weaker levels of encryption, specify minimum encryption levels in your connection profiles.

When a SafeLinx Client establishes a session with the SafeLinx Server, the wireless optimized link protocol (WLP) negotiates the level of encryption for the session with the client. After the SafeLinx Server receives the proposed level of encryption from the client, it can reject it if you establish a higher minimum level. Alternatively, if the SafeLinx Client proposes a stronger level of encryption than the minimum that the SafeLinx Server enforces, the stronger level is used. For example, if the SafeLinx Client proposes use of AES 256, and the SafeLinx Server has the minimum value set at AES 128, then AES 256 is used. If the SafeLinx Client offers less encryption than the minimum required, the SafeLinx Server forces the client to use the minimum level automatically.

In addition to the default AES encryption, you can also configure a Mobile access service to use transport layer security (TLS) encryption. If you decide to configure the service to use TLS, traffic is first secured by the default AES encryption, and then encrypted again with TLS. The redundant encryption is not itself of significant benefit.

However, the use of TLS and HTTPS can provide a secure communications solution for SafeLinx Clients on private networks that might prohibit UDP or generic TCP traffic. In such an environment, a SafeLinx Client can securely tunnel VPN traffic to the SafeLinx Server over TLS.

By default, when you add a mobile access service, three mobile network connections (MNCs) are added to the SafeLinx Server: UDP, HTTP, and HTTPS. These same three protocols are enabled by default on the SafeLinx Client. UDP provides the most efficient means of transport, but some private networks don't support UDP. To enable communications from SafeLinx Client in such environments, the client is designed to automatically cycle through the available protocols until it finds one that works. The client first tries to communicate with the SafeLinx Server over UDP. Then, if UDP is not available, it tries to tunnel communications over HTTP. Finally, if it cannot connect over HTTP, it tries to use HTTPS. If the SafeLinx Server is configured to accept TLS connections only, connections that are received through the other protocols time out, and only the TLS connection is accepted.