Hostname verification in secure AS7 connections needs improving

[pathduck]

Hey,

I have discussed this earlier in a thread (Re: 4.10 - Now SSL to AS7 by default, why was this decided?), but since we have now moved RHQ 4.13 into production I figure it's time to take it up again.

The problem is with the hostname verfication the way it's implemented today in RHQ when using secure connections to AS7 management interface.

By default, Jboss AS7 (and EAP/Wildfly) binds the management interface to localhost (127.0.0.1). Generally it's not good practice to bind to hostname, so the value will always be an IP. Obviously this causes problems when RHQ imports a server and uses the value of the bind address as the Hostname, like this:

In this instance, we bind to every interface since we want to be able to connect from other machines. For most installations, this value would be 127.0.0.1.

Of course, from the RHQ Agent perspective, this is logical, since 'Hostname' is the endpoint where the managed server is listening. From an SSL perspective this is a Bad Idea, as no-one in their right mind would use this IP as the CN in a certificate.

We use internal CA-signed certificates, all servers give the full hostname as CN and certs are signed with the CA cert which is in the truststore. However, since RHQ verifies the hostname using the value of the Jboss bind.address, hostname verification will always fail, forcing us to set Hostname verification to 'false', defeating much of the purpose of having a secure connection in the first place. Our other option is to manually or through a script set the port to management.http and secure to false after import, meaning a lot of work on our side, especially since we run many AS7 instances on each host.

I have no problems with RHQ detecting and using the management.https port as standard if it exists, but rather with the way hostname verification is performed.

My suggestion would be to have the RHQ Agent in some way use the Hostname value of the platform, since this is static, and the agent always runs locally on each machine, it only connects to local resources, and then use this value to perform hostname verification.

I am thinking of creating an RFE about this but would like to hear what others think?

Stian

[tsegismont]

We haven't got any negative feedback on the JON side as far as I know. What's bothering you with the CLI script solution? There's another possibility: create an agent plugin with a discovery callback. In the callback implementation, you can override discovered plugin configuration to match your needs. You might have a look at the RHQ server plugin to understand how discovery callbacks work. Feel free to ask questions about this here.

[pathduck]

Hi Thomas,

the biggest problem with solving this in a CLI script (apart from the work involved on my part) is that by default the Jboss management interface is mapped to 127.0.0.1. So if I script setting the Hostname to for instance "hostname1.test.local", and Jboss is only listening on 127.0.0.1 then the connection would fail.

Mostly for our environment we map Jboss management to 0.0.0.0 so the agent would be able to use the hostname, but for the future we might change this for security. It would be better if it just worked 'out of the box', assuming you have already generated proper signed certs for Jboss and setup a truststore for the agent to use.

For users running JON and EAP, is probably because both EAP 6.3 and Wildfly 8.2 still bind management to only management-http, not management-https - so I assume this is why they don't encounter it. Even though Heiko says otherwise in the other thread

Looking back I think maybe enabling management over https was a mistake on our part - it just complicates things without any major security wins (since management requests use localhost anyway). I think I wanted the Jboss management console to answer over SSL, but we don't use it at all anyway...

As to creating a pluging - I am not a Java developer, I know enough Java for problem solving, but creating something like that would be way outside scope of what I do on a daily basis