AS7 Plugin - Secure Connections to Server

Larry O'Leary loleary at redhat.com
Wed Aug 1 15:53:16 UTC 2012


On Wed, 2012-08-01 at 11:36 -0400, Stefan Negrea wrote:
> Hello Everybody,
> 
> I need some input with regards to the design & implementation for using HTTPS connections (one-way-encryption) for agent-to-AS7 communication. 
> 
> The code changes so far have been fairly simple. Basically the plugin code will detect whether the AS7 server is configured to require secure connections. Based on this, the plugin will attempt to establish either a regular http or https connection back to the server for typical management communication. Once https is enabled in AS7, the server will expect all clients to use secure connections, thus the plugin will default to https if configured. The AS7 needs to preconfigured by the users (through external means) to use certificate based encryption for the http management interface. Here is a JIRA with a good sample configuration: https://community.jboss.org/thread/178090 .
> 
> Here are the branch and commit for this work (including unit tests):
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/stefan/as7https
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=182a9c0aed0f2359fcf2eb2e6467ed36721ab069
> 
> 
> But there is one slight problem, the code above will fail by default for any self-signed certificates. In this case, the RHQ agent is no more than a regular browser (eg. Firefox). For self-signed certificates, Firefox and Chrome display a big red page with a big warning asking the user whether to proceed or not (and even give the option to permanently accept the certificate). But by default JVM will just reject self-signed certificates unless the users does some JVM pre-configuration. The code will work without any additional configuration for all certificates signed by the major certificate issuers (or any derivatives from such certificates) and will fail for self-signed certificates. Now, there are several ways to enable users to use self-signed certificates with the AS7 plugin. Below are four approaches.
> 
> 1) Rely on users to import self-signed certificates into the default JVM keystore. Here is a good guide on how to do this http://www.grim.se/guide/jre-cert . This approach does not require any changes to the code posted above, we will just need to document this in the RHQ wiki pages. 
> 
> *I expect security savvy users to create an internal certificate signer and then import this certificate in all the JVMs in the infrastructure. All certificates signed with this root certificate will then be accepted by the JVM like any other certificate signed by one of the big certificate signers.

Bad idea and not secure as the JVM may be used for other applications.
Additionally, this hadn't worked in the past when securing
agent-to-server communications as the keystore defined there overrides
the system's default.

> 2) Rely on users to provide the JVM with a certificate store that contains the certificate to be used. This is very similar to Option 1 but the users will not modify the default store, rather they will configure the JVM to use a custom store. As previous option, we will just need to document this in the RHQ wiki pages.
> 
> Step 1) Export the certificate from the server
> Step 2) Create the keystore with the given certificate: http://docs.oracle.com/javase/tutorial/security/toolsign/rstep2.html
> Step 3) Include the following line in the rhq-agent-env.sh:
> RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Djavax.net.ssl.trustStore=/path/to/keystore -Djavax.net.ssl.trustStorePassword=s3cr3t"

This is on the right track but still not ideal. Because other plug-ins
are installed and require the use of trust stores, such an
implementation is overriding the JVMs system-wide store. Additionally,
this had not worked in the past when securing agent-to-server
communications.

The standard implementation for this is to define properties specific to
the plug-in and the user specify the location of the trust store (and
key store if 2-way SSL is required) along with the required passwords
and store types. You specify these values either via command-line
arguments (non-optimal as they are for each resource) or via plug-in
configuration for that connection. Then you would use a custom SSL
factory which loaded the correct stores and configuration on a resource
basis instead of globally in the JVM. 

The fall-back is if the properties are not explicitly defined, the JVM
global option is used allowing the user to still do what you propose as
a fall-back method if they do not want to explicitly define it for each
AS7 resource.

> 
> 3) Use the same certificate store currently used to secure RHQ agent-to-server communication. Here is the wiki for securing RHQ communication: https://docs.jboss.org/author/display/RHQ/Securing+Communications (there is a section for configuring a certificate store on the agent). This option requires substantial changes in the patch posted above. I will also need to test and update the existing agent code to make sure that even if a keystore is configured, the agent will not attempt to use it for RHQ server-to-agent communication unless explicitly configured.

This could work but seems a bit like overloading. Any changes to
agent-to-server communications in the future would require us to
understand how all the plug-ins are leveraging this configuration.
Additionally, it does not account for the password differences that can
exist between keys within the trust store.

> 
> 4) Provide an option in the plugin to allow users to accept self-signed certificates. Like the HTTPS option, this will be a boolean option to allow any certificate that defaults to false. The code above will need to change to use a temporary keystore created on demand to store these self-signed certificates at run-time. This approach is NOT recommended due to exposure to man-in-the-middle attacks.

Definitely a bad idea as it defeats the purpose. The HTTPS configuration
used by AS7 is not only used for encryption but for authentication. A
man-in-the-middle could provide us with a fake certificate and obtain
the real management user name and password.

> 
> I strongly favour options 1 and 2 (and we can add notes in the RHQ documentation for both) because they are simple and give the users the most flexibility and security. And again, I think security savvy users will use option 1 with a self created certificate signer.
> 
> I do not like option 3 because it makes the agent setup more complicated. It's already non-trivial to setup RHQ server-to-agent communication, this will make things even more complex with very little gain. The AS7 plugin does not require a two-way encryption so the only advantage is that users would have one common keystore (which could be confusing). And if this certificate changes, the users will need to go through the agent setup again, which can be confusing too. 
> 
> I do not like option 4 because it exposes users to a potential man-in-the-middle attack. By clicking one option, they invariably enable long-term exposure to this threat for all AS7 communication from an agent. With the other options the user would need to take active measures if certificate changes, whereas with option 4 everything will be silent.
> 
> 
> 
> This topic is very complex by nature and we can make RHQ very complex too. For example, we can document 1 and 2 and then implement both 3 and 4 in code and have some fall-back mechanism (eg. if 4 is enabled then disregard 3). Having 4 layers of fall-back for anything is not something simple to explain or document. My inclination is to keep things as simple as possible because security savvy users are aware of the pitfalls of using self-signed certificates with Java. I also expect security savvy users to have a broader strategy devised for their entire environment with regards to certificates.
> 
> 
> Any thoughts regarding the work (code changes) I've done so far? Any thoughts regarding these options? Which ones are better or you want to see implemented? Any other options?
> 
> 
> 
> 
> Thank you,
> Stefan Negrea




More information about the rhq-devel mailing list