Chapter 2: Client Connections
NTLS (SSL) Performance Issue
For modern HSM appliances, NTLS uses 2048-bit client/server certificates for client connections, rather than
the 1024-bit certs that were considered secure in the past.
This larger certificate size requires more overhead/system resources than before. For a single connection or
just a few simultaneous connection setups, the increased overhead is insignificant.
However, in a stress environment where (say) hundreds of concurrent connections are launched at once, you
might see connections fail. The appliance attempts to get to all the incoming requests, but inevitably
experiences delay on some. It eventually does get to all the session-open requests, but in a very intense flurry
of session-opening, it might be returning responses to a given client after that client has timed out some of its
own requests.
Once connections are set up, they can remain open and working with no problem up to the limit allowed by the
appliance - 800 concurrent connections.
Workaround
Ensure that your application does not attempt to open hundreds of client connections all at the same time
(space the setups over time - the problem is not how many sessions are open, but how many are in the startup
process at the same time).
Or if high-volume simultaneous launch of sessions from a single client is unavoidable, then increase the
receive timeout value (at the client) from the default 20 seconds to some larger value that eliminates the
problem for you.
The obvious trade-off is that the higher the receive timeout value is set on each client, the longer it takes for
failed connection attempts to be recognized and corrective measures to be taken.
Timeouts
Your network connections will timeout after a period of inactivity, as described below.
SSH Timeout
SSH connections to the appliance are cleaned up and torn down when no network activity has been detected
for 15 seconds. This timeout is not configurable. If your session times out, you must open a new SSH session.
NTLS Timeout
As a general rule, do not adjust timeout settings (either via the interface or in config files) unless instructed to
do so by Thales Group Technical Support.
Changing some settings can appear to improve performance until a situation is encountered where a process
does not have time to complete due to a shortened timeout value.
Making timeouts too long will usually not cause errors, but can cause apparent performance degradation in
some situations (HA).
Default settings have been chosen with some care, and should not be modified without good reason and full
knowledge of the consequences.
SafeNet Luna Network HSM 7.3 Appliance Administration Guide
007-013576-005 Rev. A 13 December 2019 Copyright 2001-2019 Thales
39
