AS7 Plugin - Secure Connections to Server

Stefan Negrea snegrea at redhat.com
Wed Aug 1 17:23:40 UTC 2012



----- Original Message -----
> From: "Larry O'Leary" <loleary at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Wednesday, August 1, 2012 10:53:16 AM
> Subject: Re: AS7 Plugin - Secure Connections to Server
> 
> 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.


The agent-to-server comm code explicitly overrides the default keystore and only for the comm layer purposes (the settings are not applied at JVM level). This is not the case for the AS7 plugin.

I will reiterate this, from my experience a common use case is for users to create a local (for their entire environment) signing authority and import only that in each JVM. In that case, no specific certificate will ever be imported in the actual JVMs. With this signer certificate imported, each application could use any certificate signed by this "root" certificate as if it is a certificate signed by one of the major certificate signers.

> 
> > 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.

In this case all the plugins will need to use one single keystore.

> 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.


This leads to a bigger discussion. How to design a facility to make certificates and certificate stores available to plugins. Since this initial AS7 plugin patch would just provide support for one-way encryption the code is much simpler and the requirements are not as complex as agent-server comm layer. I have not evaluated yet the need to use two-way encryption with AS7 but we will not be able to implement two-way encryption without implementing a generic certificate infrastructure for plugins.

Also, the individual certificate password problem will never occur in this case because the agent is just like a simple browser. All what users would need to import into a keystore is the public cert (which is never password protected).


> 
> 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.


There is one more problem with properties listed in the agent-configuration.xml. Every time something changes or a new store needs to be added, the user will have to go through an agent reconfiguration (rhq-agent.sh --cleanconfig). I do not think it is a good idea to expose properties for every single plugin. We will just make the configuration very tedious. 

Think about this use case. The agent is configured, running, and has some resources inventoried. The user installs an AS7 server and secures the http management interface with a self-signed certificate. The user would then need to stop the agent, and then manually go through the agent re-configuration process just to pick up a keystore for one plugin. Far from ideal... That is why I think JVM level options are much better alternative. The user should put all these self-signed certificates in a single store for our agent to use. It's a more natural approach and no full agent reconfiguration every time a new certificate is needed.

Our target user for this feature should be somebody already savvy with certificates and usage with Java. If somebody goes through the trouble of securing AS7 communication channels with certificates, then I expect them to have an advanced understanding of SSL/TLS and certificates. Thus no reason to design the AS7 feature for somebody with no knowledge into this (eg. 4 layers of fallback hoping that they will get it right somehow).


Do we have any indication that our users use self-signed certificates?



> > 
> > 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.


Agree, this is one of the main reasons why I do not favor this option.


> 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.

Agree

> > 
> > 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
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list