Connecting services and agents with a secure tunnel
Agent connections that route via a tunnel offer three levels of security, each offering an incrementally more secure communication pathway:
- End-to-End encryption
- Server Authentication
- Server and Agent Authentication
To allow authentication of Services or Agents, keys and certificates must be available. MainView Middleware Monitor supports either:
- End-user provided keys and certificates
- Internally generated keys and certificates
When using end-user provided materials they must be imported into Java key stores and made available to the Agents and Services. This is likely to be required when you have strict security requirements that are not met by the internally generated certificates, or when you must integrate tightly with an existing authentication infrastructure (e.g. certificates for trusted entities are already available and must be used).
When using internally generated keys and certificates, the Java key stores are populated for you. This is likely suitable for environments where Server or Server and Agent authentication is required, but there is no need for integration with an existing authentication infrastructure.
Tunnel connections can be initiated either by the Service Tier (to a particular agent) or by the agent (to the Service Tier). This is likely to be useful in environments where firewalls or intrusion detection products are in place, and restrict the routing options between the Agent and Service Tiers.
The tunnel connection initiation can be configured per-agent via the "ConnectionInitiation" preference. It can also be set to an initial value when a bootstrap package is provisioned.
ConnectionInitiation |
|
|---|---|
0 | No tunnel |
1 | Agent initiated (TCP connection originates from the Agent tier). |
2 | Service Initiation (TCP connection originates from the Service tier). |
Service Tier tunnel configuration parameters are described in the Tunnel_Service section of the services.cfg file.
Agent Tier tunnel configuration parameters are described in Post-core-component-installation-and-configuration.
In all cases, the MainView Middleware MonitorServices tier assumes the role of a TLS Server, and MainView Middleware Monitor Agent tier assume the role of TLS clients.
Service initiated tunnels for connecting services and agents
Bootstrap packages that are provisioned with a "ConnectionInitiation" preference of "2" (equivalent to selecting the MainView Middleware Monitor Services initiate Secure Tunnel Connection to Agent option on the Agent Distribution site) must be introduced to the Subscriber Services using "hosttool". This utility is required in order that the Subscriber Services know that a tunnel must be initiated. See Managing hosts for details.
This step is not required if you deploy the Agent in a different connection initiation mode, and then later switch to a Service-initiated tunnel mode (since, at that point, the Agent is already known to the Services).
When migrating an Agent to an alternate Subscriber Service tier and the Agent is running a Service-Initiated tunnel, the Agent must be explicitly removed from the previous Subscriber Service tier. Use the Object Repository tab in the Monitor Console, or the hosttool utility.
Services configuration examples
The following examples cover various configuration scenarios, all of which are performed by editing the Tunnel_Service section of the services.cfg file. In each case, only the minimum required configuration is documented. Additional parameters can be used to further refine the configuration.
Anonymous, end-to-end encryption
In this mode, traffic is encrypted, but no authentication of either party is required. An anonymous cipher is used. This requires only that the tunnel is enabled, and the tunnel host name is set:
[Tunnel_Service]
tunnel_enabled=true
All other values can be left to default, unless an alternate configuration is required.
Agent authenticates services using internal certificates
With this configuration Agents can assert that they are connecting to trusted Services.
This is achieved by enabling internal certificates, defining an authenticating cipher suite and, after key store generation, changing the key and trust store passwords to "changedit" (and OBF encoding the password).
[Tunnel_Service]
tunnel_enabled=true
use_internal_certificates=true
ssl_include_cipher=TLS_ECDHE_RSA_WITH_RC4_128_SHA
ssl_truststore_password=OBF:1vn21ugu1s3g1uvc1tvj1uuu1s3m1ugw1vo0
ssl_keystore_password=OBF:1vn21ugu1s3g1uvc1tvj1uuu1s3m1ugw1vo0
Note that the key and trust store names are not required – internally generated certificates use fixed store names.
Mutual authentication using internal certificates
With this configuration, Agents assert that they can trust the Services, and the Services assert that the connecting Agent is trusted.
This is achieved by using the previous example, and by adding a setting to require client authentication (clients, in this context, being MainView Middleware Monitor Agents).
[Tunnel_Service]
tunnel_enabled=true
use_internal_certificates=true
ssl_client_auth=true
ssl_include_cipher=TLS_ECDHE_RSA_WITH_RC4_128_SHA
ssl_truststore_password=OBF:1vn21ugu1s3g1uvc1tvj1uuu1s3m1ugw1vo0
ssl_keystore_password=OBF:1vn21ugu1s3g1uvc1tvj1uuu1s3m1ugw1vo0
Agent authenticates services using provided certificates
With this configuration Agents can assert that they are connecting to trusted Services, using key and trust stores provided by the end-user.
[Tunnel_Service]
tunnel_enabled=true
use_internal_certificates=false
ssl_include_cipher=TLS_ECDHE_RSA_WITH_RC4_128_SHA
ssl_truststore_file=myTrustStore.jks
ssl_truststore_password=OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v
ssl_keystore_file=myKeyStore.jks
ssl_keystore_password=OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v
Note that this assumes default values for parameters such as store-types and key and trust management algorithms. Additional parameters are available to configure alternatives.
Mutual authentication using provided certificates
With this configuration Agents assert that they can trust the Services, and the Services assert that the connecting Agent is trusted.
This is achieved by using the previous example, but adding a setting to require client authentication (clients, in this context, being MainView Middleware Monitor Agents).
[Tunnel_Service]
tunnel_enabled=true
use_internal_certificates=false
ssl_include_cipher=TLS_ECDHE_RSA_WITH_RC4_128_SHA
ssl_truststore_file=myTrustStore.jks
ssl_truststore_password=OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v
ssl_keystore_file=myKeyStore.jks
ssl_keystore_password=OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v
Note that this assumes default values for parameters such as store-types and key and trust management algorithms. Additional parameters are available to configure alternatives.
Using anonymous cipher suites with a secure tunnel
MVMM Fix Pack 9.1.J provides enhanced secure agent tunnel configuration to prevent configurations where anonymous cipher suites can be enabled unintentionally.
You must use the ssl_include_ciphers configuration property to configure and enable the use of anonymous cipher suites. The use of anonymous cipher suites is not enabled if you don't use the ssl_include_ciphers configuration property.
To enable anonymous cipher suites for secure agent tunnels:
- You need to enable Tunnel Service. For more information, see the tunnel_enabled parameter in Tunnel_Service.
- You must include required cipher suites by name in the ssl_include_ciphers parameter. For more information, see Tunnel_Service.
- Do NOT disable anonymous ciphers in the Java runtime.
- Make sure that the jdk.tls.disabledAlgorithms in the Java security policy configuration file (jre/conf/security/java.security) does NOT contain the word anon.
To verify that the anonymous ciphers were configured successfully, start the MVMM Application Service (qpas) and review the tunnel log file (qpas-tunnel.log). When an anonymous cipher suite is configured successfully, informational messages are logged in the following format:
Anonymous cipher suites are not recommended, but are allowed in this configuration
tunnel> Tunnel Service configuration validation passed (1 validation message(s))
In MVMM 9.0, support for anonymous TLS cipher suites is disabled by default, and it is no longer a recommended configuration.
Earlier versions of the product allowed anonymous TLS ciphers suites. The upgrades to 9.0 version will be configured to allow anonymous cipher suites if the upgrade process determines they are required by the current product configuration in order to maintain continuity of operations.
Upgraded installations can be configured to disallow TLS anonymous cipher suites after the upgrade has completed using the following instructions.
To migrate a tunnel configuration to use certificates
This process requires that the MVMM Application Service and the MVMM Configuration Agent on all agents using a tunnel should be restarted after the configuration has changed.
It assumes the following:
- Tunnel Service is enabled (tunnel_enabled=true in services.cfg)
- Tunnel Service is using an anonymous TLS cipher suite (ssl_include in services.cfg contains an TLS cipher suite name containing "anon").
In all other cases, no migration is required (i.e. tunnel service is not enabled or anonymous TLS ciphers suites are not being used).
Update the MVMM Service tunnel configuration
Modify the Tunnel_Service section in services.cfg to use a certificate configuration as detailed earlier on this page. See sections titled:
- Agent authenticates services using internal certificates
- Mutual authentication using internal certificates
- Agent authenticates services using provided certificates
- Mutual authentication using provided certificates
Make sure to define a TLS cipher suite (using ssl_include_ciphers) that provides the appropriate security level, and requires authentication using certificates.
Restart the MVMM Application Service to have the new configuration take effect.
Note that any agents using a tunnel without certificates will no longer be able to connect to the services (until the agents themselves are migrated).
Update the MVMM Agent tunnel configuration
New Agent Bootstrap packages that use tunneling will include the required certificates. Updating to the new Agent Bootstrap package is the simplest method to update the MVMM Agent tunnel configuration.
Existing agents can be reconfigured as follows, without distributing an updated bootstrap packages.
This assumes that:
- The agent was previously distributed from an MVMM Services host that was configured with tunnelling enabled, but without certificates (i.e. using an anonymous TLS cipher suite).
- The MVMM Agent (qpea) is running
- The MVMM Configuration Agent (bmmtm_agent) is not running
In the MVMM Agent installation directory, edit the file bmmtm_agent/configuration/services/tunnel.properties.
If the following properties are not defined, add them :
ssl.truststore.file=bmtmAgentTrustStore.jks
ssl.truststore.password=OBF\:1vn21ugu1saj1v9i1v941sar1ugw1vo0
These are default values which can be changed as preferred. Make sure if using an OBF encoded password value that the ":" character is escaped as shown in the example above. This is not a pre-defined password, it is a new password that will be used to create the new Java trust store in which the certificates are stored.
Next, run the bmmtm_agent in console mode to capture the MVMM Service certificates in the agents truststore.
- Stop the bmmtm_agent if it is running.
- On Windows, run the command "bin\Agent.bat --console"
- On Unix, run the command "bin\Agent --console"
- At the "osgi>" prompt, type "trustServer YOUR-FULLY-QUALIFIED-MVMM-SERVICES.HOST.NAME"
- Inspect the presented certificate chain to make sure it is the expected host.
- Type "yes" to trust the certificate and host providing it.
An example session is shown below:
The MVMM Configuration Agent can now be started, and the tunnel connection will be established using certificates to authenticate the MVMM Services.
Configuring Anonymous TLS Cipher Suites in the MVMM Services
The following describe how to disable or enable anonynous TLS cipher sutes in the MVMM Services.
To disable anonymous TLS cipher suites in the MVMM Services
In MVMM 9.0 anonymous TLS cipher suites are not required by a new product installation. Upgrades from earlier versions may have detected tunnel configurations that require anonymous TLS cipher suites, in which case the upgrade would have enabled anonynous TLS cipher suites to allow continuity of operations.
After migrating the agent tunnel configuration to use certificates anonymous TLS cipher suites can be disabled entirely as follows.
In the product installation directory, copy the file jre/conf/security/java.disable.anon.security to jre/conf/security/java.security.
Restart the Application Service (qpas) for the changes to take effect.
To enable anonymous TLS cipher suites in the MVMM Services
In the product installation directory, copy the file jre/conf/security/java.enable.anon.security to jre/conf/security/java.security.
Restart the Application Service (qpas) for the changes to take effect.
It is not recommended to use this configuration, however it may be required to meet specific deployment requirements or as a temporary measure to facilitate migration of tunnelled agents to the use of certificates.
Configuring Anonymous TLS Cipher Suites in the MVMM Agent JRE
Agent bootstrap and JRE packages distributed from MVMM 9.0 Services will be configured to enable or disable anonymous TLS cipher suites according to the MVMM Server configuration. By default, anonymous TLS cipher suites will be disabled.
The JRE may need to be configured differently, depending on monitoring or security requirements.
To disable anonymous TLS cipher suites in the MVMM Agent JRE
On windows - in the JRE directory of the agent installation, copy the file jre/windows-x86-64/jre8/conf/security/java.disable.anon.security to jre/windows-x86-64/jre8/conf/security/java.security.
On linux - in the JRE directory of the agent installation, copy the file jre/linux-x86-64/jre8/conf/security/java.disable.anon.security to jre/linux-x86-64/jre8/conf/security/java.security.
On AIX - in the JRE directory of the agent installation, copy the file jre/aix-ppc-64/jre8/lib/security/java.disable.anon.security to jre/aix-ppc-64/jre8/lib/security/java.security.
On HP-UX - in the JRE directory of the agent installation, copy the file jre/hpux-ia-64/jre8/lib/security/java.disable.anon.security to jre/hpux-ia-64/jre8/lib/security/java.security.
Restart any Java extensions using the Agent JRE for the changes to take effect.
To enable anonymous TLS cipher suites in the MVMM Agent JRE
On windows - in the JRE directory of the agent installation, copy the file jre/windows-x86-64/jre8/conf/security/java.enable.anon.security to jre/windows-x86-64/jre8/conf/security/java.security.
On linux - in the JRE directory of the agent installation, copy the file jre/linux-x86-64/jre8/conf/security/java.enable.anon.security to jre/linux-x86-64/jre8/conf/security/java.security.
On AIX - in the JRE directory of the agent installation, copy the file jre/aix-ppc-64/jre8/lib/security/java.enable.anon.security to jre/aix-ppc-64/jre8/lib/security/java.security.
On HP-UX - in the JRE directory of the agent installation, copy the file jre/hpux-ia-64/jre8/lib/security/java.enable.anon.security to jre/hpux-ia-64/jre8/lib/security/java.security.
Restart the Application Service (qpas) for the changes to take effect.
It is not recommended to use this configuration, however it may be required to meet specific deployment requirements or as a temporary measure to facilitate migration of tunnelled agents to the use of certificates.
To configure other JREs
Most JREs provide a java.security file that defines which cipher suites are disabled in a property named "jdk.tls.disabledAlgorithms". Note that changes here impact all users of the JRE.
On platforms where MVMM does not provide a JRE, refer to the documentation of the JRE vendor for details and alternative configuration options that might be available.