Bug 1301970 - Some secure-socket-protocol properties are not ready for list of protocols
Summary: Some secure-socket-protocol properties are not ready for list of protocols
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Communications Subsystem
Version: JON 3.3.6
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ER01
: JON 3.3.7
Assignee: Simeon Pinder
QA Contact: Filip Brychta
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-26 13:12 UTC by Filip Brychta
Modified: 2017-02-15 03:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-31 16:59:35 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:1785 normal SHIPPED_LIVE Moderate: Red Hat JBoss Operations Network 3.3.7 security and bug fix update 2017-09-05 16:48:45 UTC
Red Hat Bugzilla 1277389 None CLOSED Default values for secure-socket-protocol parameters in rhq-server.properties and standalone-full.xml need updated to a ... 2019-08-02 19:02:06 UTC
Red Hat Knowledge Base (Solution) 2481871 None None None 2016-08-02 12:09:25 UTC

Internal Links: 1277389

Description Filip Brychta 2016-01-26 13:12:04 UTC
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 14:09:37 UTC
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 14:30:54 UTC
@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 14:42:09 UTC
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 18:57:05 UTC
Based on previous comments closing as not a bug

Comment 5 dsteigne 2016-08-02 12:07:56 UTC
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 12:08:54 UTC
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 16:59:35 UTC
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.