AS7 Plugin - Secure Connections to Server

Charles Crouch ccrouch at redhat.com
Wed Aug 1 18:37:48 UTC 2012



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

It wasn't when I looked at the corresponding BZ yesterday.

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