AS7 Plugin - Secure Connections to Server

Michael Foley mfoley at redhat.com
Wed Aug 1 17:12:21 UTC 2012


Is this targetted to be cherry-picked for JON 3.1.1? 

If it is targetted for JON 3.1.1, I just wanted to bring up that the JON 3.1.1 Code Freeze Milestone is August 14th. Features delivered after that ...well ... that really condenses the amount of time QE has to qualify ... or the schedule shifts. So the more complex options ... there may be implications with the schedule with that if it takes longer to implement and test. 


So ... I am +1 on option 1 or 2 for JON 3.1.1. 


If the feature is for RHQ ... or a JON milestone after JON 3.1.1 ... then I am not opinionated. 


Regards, 


Mike 
----- Original Message -----

From: "Stefan Negrea" <snegrea at redhat.com> 
To: "rhq-devel" <rhq-devel at lists.fedorahosted.org> 
Sent: Wednesday, August 1, 2012 11:36:23 AM 
Subject: AS7 Plugin - Secure Connections to Server 

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. 


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" 


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. 


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. 


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 

Software Engineer 
_______________________________________________ 
rhq-devel mailing list 
rhq-devel at lists.fedorahosted.org 
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20120801/15cf8711/attachment.html>


More information about the rhq-devel mailing list