Observer OMS : Observer Management Server (OMS) : Understanding OMS : Understanding the Transport Layer Security (TLS) setting
Understanding the Transport Layer Security (TLS) setting
OMS can ensure managed assets use no lower than a minimum version of TLS for network communication. For your security, assets do not establish network connections with any web browser or Observer Platform product that fails to negotiate this minimum TLS version or higher.
All managed assets attempt to negotiate network connections using TLS 1.2—regardless of your configured TLS minimum. However, if TLS 1.2 is not a cryptographic protocol that can be mutually negotiated, then the default behavior is for the client and host to negotiate the use of TLS 1.1 instead. If TLS 1.1 cannot be negotiated, this behavior continues in that the client and host attempt to use TLS 1.0. This “fall back” is commonplace for web applications and is meant to ease network compatibility between devices and web services, but a malicious user or group can take advantage of this behavior. Increasing the minimum TLS version reduces how accommodating the host is to client connections but security is increased.
The TLS minimum applies to HTTPS sessions and asset-to-asset communication. This means all interaction with OMS or Apex through the web interface must be made using a web browser that supports the minimum TLS version or higher. This also affects browser-like applications like REST API clients and other software that can send and receive HTTPS requests, as these must meet the minimum TLS version or higher too. Likewise, as an example of asset-to-asset communication, network trending data transferred between a GigaStor system and Apex is protected at no less than the minimum TLS version—and TLS 1.2 is always attempted first. All communication between assets follows the web certificate trust model that TLS is the basis of.
Note: The TLS setting does not change the security of your notification settings. All SNMP traps, Syslog messages, and email notifications use their own security measures.
The minimum TLS setting does not set which TLS version gets used; instead, it determines which versions of TLS will never get used. Managed assets cannot establish a network connection with each other or with a web browser that does not meet the minimum TLS version or higher. Some example outcomes of your minimum TLS choice:
 
If TLS 1.1 is set as the minimum version, then TLS 1.0 cannot be negotiated or used.
If TLS 1.2 is set as the minimum version, then TLS 1.1 or TLS 1.0 cannot be negotiated or used.
 
Forcing a minimum TLS version helps mitigate security risks found in older TLS versions. Most of what causes older TLS versions to be more susceptible to cryptographic attack is the quality and implementation of the cipher suites available to that TLS version. A common way to exploit any cryptographic vulnerabilities is for a client to disable newer and safer TLS versions on their web browser, application, or device, in the hope that the host negotiates to a less secure version. By forcing a minimum TLS version, malicious users or groups wanting to connect to assets at a less secure TLS version simply cannot do so. These potentially less secure connections are not allowed.
Choosing a minimum of TLS 1.1 or TLS 1.2, while more secure, can interfere with specific older versions of assets. If you use an asset managed by OMS that includes or is within versions v17.0.0.0 to v17.0.6.0, those assets will not be able to communicate with OMS or other managed assets unless TLS 1.0 is set as the minimum. It is recommended you upgrade these assets to the latest available version if you want to set the minimum TLS version to TLS 1.1 or 1.2 successfully.
The TLS minimum setting is backwards compatible with v15 and v16 assets. Backwards compatibility is achieved because older OMS-managed assets that use a pre-shared key file (*.OEK) are neither positively or negatively affected by the minimum TLS setting. These legacy assets continue to use the pre-shared OEK key file.