Bug 1301970 - Some secure-socket-protocol properties are not ready for list of protocols
Some secure-socket-protocol properties are not ready for list of protocols
Status: CLOSED ERRATA
Product: JBoss Operations Network
Classification: JBoss
Component: Communications Subsystem (Show other bugs)
JON 3.3.6
Unspecified Unspecified
urgent Severity urgent
: ER01
: JON 3.3.7
Assigned To: Simeon Pinder
Filip Brychta
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-26 08:12 EST by Filip Brychta
Modified: 2017-02-14 22:09 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-31 12:59:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2481871 None None None 2016-08-02 08:09 EDT

  None (edit)
Description Filip Brychta 2016-01-26 08:12:04 EST
Description of problem:
See bz1277389
To fix the bz1277389 rhq.server.tomcat.security.secure-socket-protocol was set to TLSv1,TLSv1.1,TLSv1.2
When you try to set the same list of protocols to other some secure-socket-protocol properties it will fail.

Following properties are in both rhq-server.properties and in agent-configuration.xml:
rhq.communications.connector.security.secure-socket-protocol
rhq.server.client.security.secure-socket-protocol

when you set those to any list e.g. TLSv1,TLSv1.1,TLSv1.2 it will fail with Caused by: java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1 SSLContext not available

Version-Release number of selected component (if applicable):
JON3.3.5.ER01

How reproducible:
Always

Steps to Reproduce:
1. set rhq.communications.connector.security.secure-socket-protocol or rhq.server.client.security.secure-socket-protocol in rhq-server.properties or agent-configuration.xml to TLSv1,TLSv1.1,TLSv1.2
2. start server
3. start agent using --cleanconfig

Actual results:
server.log:
02:27:41,791 ERROR [org.rhq.enterprise.communications.command.client.ClientCommandSenderTask] (http-/0.0.0.0:7443-2) {ClientCommandSenderTask.send-failed}Failed to send command [Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.timeout=10000, rhq.send-throttle=true}]; params=[{invocation=NameBasedInvocation[ping], targetInterfaceName=org.rhq.enterprise.communications.Ping}]]. Cause: java.lang.reflect.InvocationTargetException:null -> java.lang.RuntimeException:Unable to create customized SSL socket factory -> java.io.IOException:Error creating socket factory SSL context: TLSv1,TLSv1.1,TLSv1.2 SSLContext not available. Cause: java.lang.reflect.InvocationTargetException

agent:
Caused by: java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1 SSLContext not available

Expected results:
It should be possible to use a list of protocols to follow behavior of rhq.server.tomcat.security.secure-socket-protocol
Comment 1 Michael Burman 2016-01-26 09:09:37 EST
I think this was intentional on BZ 1277389 to leave these two settings alone and to TLS value instead of changing protocol names on the other parameters also. 

The implementation is different on the agent-side and the value is passed to  SSLContext to get the protocol. And as you noticed, it does not allow such list to be given as parameter.
Comment 2 Simeon Pinder 2016-01-26 09:30:54 EST
@Filip, I'm not sure if that range of settings is actually appropriate for other properties.  Larry did a fair amount of work determining that the changes only needed to happen for "rhq.server.tomcat.security.secure-socket-protocol".  Putting a needinfo on him to comment further here.
Comment 3 Larry O'Leary 2016-01-26 09:42:09 EST
Comment 1 and comment 2 are correct.

RHQ uses a different implementation for SSL when using sslsocket. It is based on an out-dated example that utilizes SSLContext. Not only does this not support a list of protocols, it also does not really support a protocol at all. Instead, its protocol is more like a protocol family or highest version preference. 

When we discussed the fix for BZ 1277389 it originally identified these properties as needing updating as well. However, that would require the underlying socket implementation for sslsocket to be rewritten. The risk involved in such a change was too great for the maintenance stream.

Therefore this is not a bug. The only property set that supports the actual protocol list are the Tomcat specific properties.

@Filip my recommendation is to update/document the test case and close this BZ as not a bug.
Comment 4 Filip Brychta 2016-01-26 13:57:05 EST
Based on previous comments closing as not a bug
Comment 5 dsteigne 2016-08-02 08:07:56 EDT
Re-opening for 3.3.6, it appears that unless you explicitly set rhq.communications.connector.security.secure-socket-protocol to TLS on the agent configuration, don't let it use the default, which appears to be TLSv1,TLSv1.1,TLSv1.2 with the 3.3.6 update.  You will receive the same error in the description when trying to start the agent:

2016-08-01 13:03:27,818 FATAL [main] (org.rhq.enterprise.agent.AgentMain)- {AgentMain.startup-error}The agent encountered an error during startup and must abort
java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1,TLSv1.2 SSLContext not available
        at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
        at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
        at org.jboss.remoting.security.SSLSocketBuilder.createServerSocketFactorySSLContext(SSLSocketBuilder.java:1197)
        at org.jboss.remoting.security.SSLSocketBuilder.createCustomServerSocketFactory(SSLSocketBuilder.java:385)
        at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:366)
        at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:345)
        at org.jboss.remoting.security.SSLServerSocketFactoryService.start(SSLServerSocketFactoryService.java:61)
        at org.rhq.enterprise.communications.ServiceContainer.initializeSecurityServices(ServiceContainer.java:1393)
        at org.rhq.enterprise.communications.ServiceContainer.setupServerConnector(ServiceContainer.java:1240)
        at org.rhq.enterprise.communications.ServiceContainer.start(ServiceContainer.java:596)
        at org.rhq.enterprise.communications.ServiceContainer.start(ServiceContainer.java:514)
        at org.rhq.enterprise.agent.AgentMain.startCommServices(AgentMain.java:2542)
        at org.rhq.enterprise.agent.AgentMain.start(AgentMain.java:715)
        at org.rhq.enterprise.agent.AgentMain.main(AgentMain.java:461)
2016-08-01 13:03:27,819 INFO  [main] (org.rhq.enterprise.agent.AgentMain)- {AgentMain.shutting-down}Agent is being shut down...
Comment 11 Filip Brychta 2016-08-03 08:08:54 EDT
Just to avoid confusion the original description of this bz was correctly closed as not a bug - TLSv1,TLSv1.1,TLSv1.2 is NOT expected to work. Reason for reopening is described in comment 5.

Workaround for the issue is to set rhq.communications.connector.security.secure-socket-protocol explicitly to TLS which can be done following way:
echo "setconfig rhq.communications.connector.security.secure-socket-protocol=TLS" | "${RHQ_AGENT_HOME}/bin/rhq-agent.sh" --nostart
Comment 22 errata-xmlrpc 2016-08-31 12:59:35 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-1785.html

Note You need to log in before you can comment on or make changes to this bug.