Bug 1078204 - SSL connector fails to start if cipher-suite="ALL"
Summary: SSL connector fails to start if cipher-suite="ALL"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER10
: EAP 6.3.0
Assignee: Emmanuel Hugonnet (ehsavoie)
QA Contact: Radim Hatlapatka
Russell Dickenson
URL:
Whiteboard:
Depends On: 1100799 1113025
Blocks: 1032164 1111058 1111059 1116292 1116302 1123304 1132360
TreeView+ depends on / blocked
 
Reported: 2014-03-19 11:41 UTC by Radim Hatlapatka
Modified: 2015-09-25 17:35 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-06 14:37:41 UTC
Type: Bug


Attachments (Terms of Use)
keystore (1.31 KB, application/octet-stream)
2014-05-07 12:30 UTC, baranowb
no flags Details
Patch to add support for OpenSSL syntax in defining ciphers (108.38 KB, patch)
2014-05-19 13:19 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
Cleaner patch using logging instead of System.out (108.13 KB, patch)
2014-05-22 06:23 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
Patch to add support for OpenSSL syntax in defining ciphers (108.46 KB, patch)
2014-05-22 06:51 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
keys and certs usable for testing purposes (19.27 KB, application/zip)
2014-06-20 08:55 UTC, Radim Hatlapatka
no flags Details
server.log with ECDSA as cipher-suite (112.57 KB, text/plain)
2014-06-24 12:25 UTC, Radim Hatlapatka
no flags Details
Patch that fixes the missing aliases and adds some debug messages to help testing (11.35 KB, patch)
2014-06-25 08:00 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
For the '+' case I missed (1.63 KB, patch)
2014-06-27 07:47 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
Fix both issues with the + (1.90 KB, patch)
2014-06-27 09:26 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
Fix both issues with the '+' (2.14 KB, patch)
2014-06-27 09:55 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details | Diff
patch to fix sepparator for cipher suites (1.16 KB, patch)
2014-06-30 11:22 UTC, Radim Hatlapatka
no flags Details | Diff
Patch for typo in cipher suite name (577 bytes, patch)
2014-07-03 11:11 UTC, Radim Hatlapatka
no flags Details | Diff
List of ciphers which are not listed in org.apache.tomcat.util.net.jsse.openssl.Ciphers (1.27 KB, text/plain)
2014-07-03 11:22 UTC, Radim Hatlapatka
no flags Details


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker JBWEB-299 Major Coding In Progress Add support for OpenSSL syntax when defining ciphers 2018-05-18 17:04:41 UTC
JBoss Issue Tracker XNIO-229 Major Closed Add support for ALL expression to define the list of ciphers ands protocols more easily. 2018-05-18 17:04:41 UTC
Red Hat Bugzilla 1032164 None None None Never
Red Hat Bugzilla 1111058 None None None Never

Internal Links: 1032164 1111058

Description Radim Hatlapatka 2014-03-19 11:41:32 UTC
Description of problem:
SSL connector fails to start if cipher-suite="ALL" even though in the xsd schema it is defined as default value, see error message [1]


Version-Release number of selected component (if applicable): EAP 6.3.0.DR2, EAP 6.3.0.DR3, EAP 6.2.0.DR4


How reproducible: always


Steps to Reproduce:
1. Add https connector with ssl configuration and define cipher-suite="ALL" (similarly to [2]
2. start the EAP and see error message during startup


Actual results:
exception is thrown [1] and https connector is not started


Expected results:
Starts without error and https connector is started


Additional info:
The issue was introduced by this commit https://source.jboss.org/changelog/JBossWeb?cs=2322. If you don't define the cipher-suite attribute ciphers is set to null and then getEnabledCiphers returns sslProxy.getDefaultCipherSuites(), if you define it to value which it doesn't find between supportedCiphers, it ends up with the error [1].

Per EAP 6 schema definition for jboss-as-web in default should be used value ALL => in case of value ALL it should from my opinion behave the same way as with null value (using default cipher suites)


[1]
 01:36:53,584 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-7) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
127         at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
128         at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
129         at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
130         at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
131         at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-4.jar:7.4.0.Final-redhat-4]
132         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
133         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
134         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
135         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
136         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
137 Caused by: java.io.IOException: JBWEB002081: No cipher match
138         at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
139         at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
140         ... 9 more
141 
142 01:36:53,603 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error startin    g web connector
143         at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
144         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
145         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
146         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
147         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
148         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
149 Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
150         at org.apache.catalina.connector.Connector.init(Connector.java:985)
151         at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
152         ... 5 more



[2] ssl connector setting
 <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
              <ssl name="http-perf" key-alias="jboss" password="jbossas" certificate-key-file="${jboss.server.config.dir}/server.keystore" cipher-suite="ALL" protocol="ALL" verify-client="none" verify-depth="10" session-cache-size="1" sess
  </connector>

Comment 1 Jan Stefl 2014-03-19 12:09:56 UTC
The issue is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1032164 | EAP https connector defaults

Comment 2 Michal Karm Babacek 2014-03-19 12:16:34 UTC
One might find these interesting as well:

Not a bug - just a configuration stuff
[JBWEB-292] Http11Nio loaded, JBWEB002081: No cipher match

What JDK supports which cipher suites?
[JBWEB-294] The same JSSE cipher-suite behaves differently with various JDKs


The question I would like to highlight is, how one aligns OpenSSL cipher-suite syntax (native implementation, native="true") and JSSE cipher-suite syntax (native="false")?


[JBWEB-292] https://issues.jboss.org/browse/JBWEB-292
[JBWEB-294] https://issues.jboss.org/browse/JBWEB-294

Comment 3 baranowb 2014-05-07 12:30:26 UTC
Created attachment 893253 [details]
keystore

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
	      <ssl name="http-perf" key-alias="jboss" password="jbossas" certificate-key-file="${jboss.server.config.dir}/server.keystore" cipher-suite="ALL" protocol="ALL" verify-client="none" verify-depth="10" session-cache-size="1"/>
	    </connector>

Comment 5 baranowb 2014-05-08 10:12:36 UTC
Michal - open SSL supports 'ALL' by default iirc [1], [2] so there is no mapping required. 

In case non-native, if this is a real must:
        SSLContext context2 = SSLContext.getDefault();
        SSLSocketFactory sf = context2.getSocketFactory();
        String[] cipherSuites = sf.getSupportedCipherSuites();
        String cipherList = Arrays.toString(cipherSuites).replace("[", "").replace("]", "");

should be enough - since JDOC for set suites[3] has this statement 'Each cipher suite in the suites parameter must have been listed by getSupportedCipherSuites()' and there is no magical 'ALL' in it.

However, WebSubsystemParser and WebConnectorAdd does not resolve default attributes value, probably [4] takes care of this( not sure, since I cant open it)

IMHO, the default == ALL in case of cipher suites is wrong. If factories allow null/default cipher suites to be used, forcing ALL is wrong.

[1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ciphers+1
[2] https://www.openssl.org/docs/apps/ciphers.html
[3] http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLSocket.html#setEnabledCipherSuites(java.lang.String[])
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1032164

Comment 7 baranowb 2014-05-08 10:32:50 UTC
WFLY dropped support for default values( iirc SRT pushed this?) https://github.com/wildfly/wildfly/blob/master/security/subsystem/src/main/java/org/jboss/as/security/JSSEResourceDefinition.java#L69

EAP should probably drop it as well.

Comment 8 Jean-frederic Clere 2014-05-08 10:36:42 UTC
Note the related BZ 1032164.

Comment 9 Radim Hatlapatka 2014-05-09 09:29:38 UTC
The main issue is that scheme claims default value for cipher-suite as 'ALL'. So customer expects that setting cipher-suite="ALL" will work but it doesn't, at least not for JSSE.

Comment 10 Emmanuel Hugonnet (ehsavoie) 2014-05-16 12:38:30 UTC
Working on implementing openSSL syntax for cipher selection.

Comment 11 Emmanuel Hugonnet (ehsavoie) 2014-05-19 13:19:12 UTC
Created attachment 897144 [details]
Patch to add support for OpenSSL syntax in defining ciphers

Now you can use the openSSL syntax to define which ciphers to use and also redefine the default cipher suite.

Comment 12 Emmanuel Hugonnet (ehsavoie) 2014-05-19 13:20:19 UTC
Adding link to similar support in XNIO for upstream

Comment 13 JBoss JIRA Server 2014-05-20 08:01:30 UTC
Emmanuel Hugonnet <ehugonne@redhat.com> updated the status of jira JBWEB-299 to Coding In Progress

Comment 16 Paul Gier 2014-05-21 16:57:46 UTC
Providing dev ack on behalf of ehsavioe

Comment 17 Emmanuel Hugonnet (ehsavoie) 2014-05-22 06:23:12 UTC
Created attachment 898220 [details]
Cleaner patch using logging instead of System.out

Comment 18 Emmanuel Hugonnet (ehsavoie) 2014-05-22 06:51:20 UTC
Created attachment 898235 [details]
Patch to add support for OpenSSL syntax in defining ciphers

Comment 19 Radim Hatlapatka 2014-06-19 07:22:39 UTC
I have verified that the original issue (setting cipher-suite="ALL" as is defined in schema the default value) works.

The patch brings whole new functionality which allows using openssl syntax even when natives are not enabled. I have created documentation BZ#1111058 which should describe this new feature.

Comment 21 Radim Hatlapatka 2014-06-19 15:30:54 UTC
I am checking different CIPHER_STRINGS from [1] and I have found out that some of them are definable on server but when I try to connect using openssl it fails with this message shown in server log [2].


This occurs for DSS, aDSS, CAMELLIA128, CAMELLIA256, CAMELLIA and potentially with some others.


[1] https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
[2]
15:57:52,787 DEBUG [org.apache.tomcat.util] (http-/127.0.0.1:8443-1) JBWEB003006: Handshake failed: java.io.IOException: JBWEB002042: SSL handshake failed, cipher suite in SSL Session is SSL_NULL_WITH_NULL_NULL
	at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:185) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:1114) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

Comment 22 Radim Hatlapatka 2014-06-19 15:32:36 UTC
I am getting the error after openssl request

Comment 25 Jean-frederic Clere 2014-06-20 08:13:19 UTC
CAMELIA ciphers are patented. I think they shouldn't be in OpenSSL and they should be in JVM that have paid for the patent.

Comment 27 Radim Hatlapatka 2014-06-20 08:53:50 UTC
Web subsystem part of standalone config [1], openssl command I am using [2], the test keys I am providing in attachment.

Also if I configure DES and I don't specify in openssl client to explicitly use DES (-cipher DES) then I am getting handshake failure with message in server log. If I specify it, handshake is successful (this is true only to DES)



[1]
        <subsystem xmlns="urn:jboss:domain:web:2.1" default-virtual-server="default-host" native="false">
            <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
                <ssl name="ssl" key-alias="javaserver" password="tomcat" certificate-key-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/server-cert-key.jks" cipher-suite="DSS" verify-client="true" certificate-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/server-cert-key.jks" ca-certificate-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/ca-cert.jks"/>
            </connector>

[2] openssl s_client -connect 127.0.0.1:8443 -msg -debug -state -CAfile /home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/myca.crt -cert /home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/client.pem -key /home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/client.key -cipher DSS <<< "GET http://localhost/ HTTP/1.1$'\n'$'\n'"

Comment 28 Radim Hatlapatka 2014-06-20 08:55:01 UTC
Created attachment 910709 [details]
keys and certs usable for testing purposes

Comment 32 Jan Stefl 2014-06-20 10:12:57 UTC
 * This big patch introduced in ER7 requires complex testing.
 * Because of that we are unable to finish proper testing this week. 
   We have tested most risky parts so far and we plan to finish 
   testing during next week.

Comment 33 Radim Hatlapatka 2014-06-23 13:15:18 UTC
The difference between the supported ciphers is caused by algorithm used to generate the keys (RSA vs DSA), with DSA it finds appropriate cipher and handshake is successful, with RSA it doesn't and causes handshake failure with the error message shown in Comment 21

Comment 34 Radim Hatlapatka 2014-06-24 12:22:09 UTC
If I specify ECDSA as a cipher-suite it fails to start the https connector with  No cipher match error.

When I have checked supported ciphers on my JDK there are ECDSA ciphers (e.g. TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA)

If I start EAP with -Djavax.net.debug=ssl, I am getting [1], where it you can see that there are checked only stronger versions of ECDSA ciphers, is there any reason why this cipher is not matched even checked?

14:09:51,180 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
14:09:51,181 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
14:09:51,181 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
14:09:51,181 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
14:09:51,182 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
14:09:51,182 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
14:09:51,183 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA
14:09:51,183 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
14:09:51,183 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
14:09:51,184 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
14:09:51,184 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
14:09:51,184 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
14:09:51,185 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
14:09:51,185 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
14:09:51,189 INFO  [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.0.Final-redhat-3
14:09:51,185 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
14:09:51,192 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
14:09:51,192 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
14:09:51,193 INFO  [stdout] (MSC service thread 1-7) Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
14:09:51,195 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-7) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
	at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getEnabledCiphers(JSSESocketFactory.java:211) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:428) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:162) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:973) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:174) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.apache.catalina.connector.Connector.init(Connector.java:985) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:318) [jboss-as-web-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

14:09:51,196 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:376)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
	at org.apache.catalina.connector.Connector.init(Connector.java:987)
	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:318)
	... 5 more

Comment 35 Radim Hatlapatka 2014-06-24 12:25:30 UTC
Created attachment 911706 [details]
server.log with ECDSA as cipher-suite

https connector setting:

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
   <ssl name="ssl" key-alias="javaserver" password="tomcat" certificate-key-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/keystore-dsa.jks" 
     cipher-suite="ECDSA" protocol="ALL" verify-client="true" certificate-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/keystore-dsa.jks" 
     ca-certificate-file="/home/rhatlapa/projects/redhat_projects/eap-cipher-suite/target/classes/ssl/ca-cert.jks" ca-certificate-password="tomcat"/>

Comment 36 Emmanuel Hugonnet (ehsavoie) 2014-06-25 08:00:33 UTC
Created attachment 911968 [details]
Patch that fixes the missing aliases and adds some debug messages to help testing

Comment 38 Radim Hatlapatka 2014-06-27 06:26:54 UTC
According to [1] in [2] + character has a special meaning (the same as AND operator) and this case is not handled by the patch.

You can try to define cipher-suite as "AES+RSA" and no matching ciphers even though ciphers corresponding to this expression are there, (e.g. TLS_RSA_WITH_AES_128_CBC_SHA)



[1]
Lists of cipher suites can be combined in a single cipher string using the + character. This is used as a logical and operation. For example SHA1+DES represents all cipher suites containing the SHA1 and the DES algorithms.

[2] 
https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

Comment 39 Emmanuel Hugonnet (ehsavoie) 2014-06-27 06:49:59 UTC
Hum, I think it works with AES:+RSA

Comment 40 Radim Hatlapatka 2014-06-27 07:05:24 UTC
In such case it has different meaning [1] and you will get even ciphers like this: SSL_RSA_WITH_NULL_MD5


[1] 
Taken from https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT:

Each cipher string can be optionally preceded by the characters !, - or +.
 
* If + is used then the ciphers are moved to the end of the list. This option doesn't add any new ciphers it just moves matching existing ones.

Comment 41 Emmanuel Hugonnet (ehsavoie) 2014-06-27 07:28:09 UTC
I missed this one :(
I've fixed it if this is required.

Comment 42 Radim Hatlapatka 2014-06-27 07:37:58 UTC
It needs to be either fixed or documented as unsupported case.

Comment 43 Emmanuel Hugonnet (ehsavoie) 2014-06-27 07:47:42 UTC
Created attachment 912705 [details]
For the '+' case I missed

Comment 44 Radim Hatlapatka 2014-06-27 09:01:31 UTC
I have tried your patch and it looks OK.

If I understand correctly to this [1] doing something like this AES+SHA:+ECDHE shouldn't change allowed ciphers in comparison to AES+SHA, it should just move the ECDHE ciphers to the end of the list.

The actual behavior is that ECDHE ciphers are also added.




[1]
If + is used then the ciphers are moved to the end of the list. This option doesn't add any new ciphers it just moves matching existing ones.

Comment 45 Emmanuel Hugonnet (ehsavoie) 2014-06-27 09:26:30 UTC
Created attachment 912734 [details]
Fix both issues with the +

Comment 46 Emmanuel Hugonnet (ehsavoie) 2014-06-27 09:55:58 UTC
Created attachment 912744 [details]
Fix both issues with the '+'

Comment 47 Radim Hatlapatka 2014-06-27 12:49:01 UTC
Setting of allowed ciphers is not properly renewed with changed cipher-suite value.

/subsystem=web/connector=https/ssl=configuration:write-attribute(name=cipher-suite, value="AES+RSA")
reload

-- ciphers found


/subsystem=web/connector=https/ssl=configuration:write-attribute(name=cipher-suite, value="AES+RSA+DES")
reload

-- no ciphers found (https connectors fails to stard due cipher no match), that's correct

setting back the AES+RSA
/subsystem=web/connector=https/ssl=configuration:write-attribute(name=cipher-suite, value="AES+RSA")
reload

-- no ciphers found - the same ciphers as first time should be used.

Comment 49 Kabir Khan 2014-06-27 15:52:55 UTC
Radim, we think https://bugzilla.redhat.com/show_bug.cgi?id=1078204#c47 is a separate issue and should have a separate BZ. Otherwise this one will never get resolved. 

The underlying feature, and so the testing, is happening very late in the cycle so I think PM needs to decide how important this feature really is. Perhaps the issue https://bugzilla.redhat.com/show_bug.cgi?id=1078204#c47 has been there all along, and is uncovered by the new testing? Emmanuel points out that it might be related to SSL config in the JVM.

Comment 50 Radim Hatlapatka 2014-06-30 09:11:06 UTC
The issue described in https://bugzilla.redhat.com/show_bug.cgi?id=1078204#c47 doesn't seem as JVM issue to me rather as an issue with the '+'

The issue is about setting via '+' (logical AND) empty set for ciphers (you can use HIGH+LOW) and then setting back "HIGH" it remains as the set is still empty even though it shouldn't be.

Setting empty set using ! operator works fine (HIGH:!HIGH) results in empty set, setting again HIGH correctly updates the setting

Comment 52 Jean-frederic Clere 2014-06-30 09:39:50 UTC
+++
[jfclere@jfcpc build]$ openssl ciphers -v 'HIGH+LOW:!LOW'
Error in cipher list
140358773630848:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314:
+++
Looks OK.

+++
[jfclere@jfcpc build]$ openssl ciphers -v 'HIGH:!HIGH'
Error in cipher list
140025989060480:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314:
+++
Looks OK.

Comment 53 Radim Hatlapatka 2014-06-30 10:00:28 UTC
The behavior for empty set is correct, incorrect is the additional step, when you change the configuration back e.g. to HIGH, you will get after reload "no matching ciphers" and you need to restart the server to get proper matching ciphers.

This is true only for '+' as AND operator, with '!' it works as expected

Comment 54 Radim Hatlapatka 2014-06-30 11:22:35 UTC
Created attachment 913335 [details]
patch to fix sepparator for cipher suites

Separator can be also a comma or space, see [1]. Attaching proposed patch.

[1] https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

Comment 55 Kabir Khan 2014-06-30 11:40:06 UTC
I've debugged the issue from #47. The problem is in line 633 of the patch at https://bugzilla.redhat.com/attachment.cgi?id=912744&action=diff. It needs to make a defensive copy of the list got in line 633.

On boot the entry for AES contains a lot of entries. After setting to AES+RSA, the AES entry only contains the common entries. Once trying something which does not exist, like AES+RSA+DES, the AES entry gets cleared.

Something along the lines of this should work since then the list stored in aliases is not modified:
L633: List<Ciphers> result = new ArrayList(aliases.get(intersections[0]));

Comment 56 Kabir Khan 2014-06-30 11:44:42 UTC
The aliases map is static, so a reload uses the same copy across reloads. A restart uses a fresh jvm and so reinitialises the map.

Comment 57 Radim Hatlapatka 2014-06-30 15:08:05 UTC
Comment on attachment 913335 [details]
patch to fix sepparator for cipher suites

From my testing this patch fixes only space separators, for commas the patch would need to be more complicated.

Comment 58 Radim Hatlapatka 2014-07-01 08:02:00 UTC
Regarding the separator for openssl cipher suites:

The code is currently written the way, that comma is separator for JSSE ciphers, and if you use comma between the ciphers it is automatically considered that only JSSE ciphers are listed.

Allowing commas as separator would require more significant changes in the code and would allow mixture of using JSSE syntax and openssl syntax at the same time. This is a question if we want allow this behavior.

I would suggest rather to specify in documentation the behavior regarding the separators

Comment 60 Radim Hatlapatka 2014-07-03 11:11:06 UTC
Created attachment 914449 [details]
Patch for typo in cipher suite name

Fix for typo in cipher suite name

Comment 61 Radim Hatlapatka 2014-07-03 11:22:11 UTC
Created attachment 914450 [details]
List of ciphers which are not listed in org.apache.tomcat.util.net.jsse.openssl.Ciphers

List of cipher suite names https://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES which are not defined in org.apache.tomcat.util.net.jsse.openssl.Ciphers in (JBossWeb).

Is there any particular reason why they are not defined?

Comment 62 Jean-frederic Clere 2014-07-03 12:36:12 UTC
Probably because they aren't safe to use. At least a quick look in the list shows that most of them arent' safe.
Arun any comments?

Comment 64 Jean-frederic Clere 2014-07-03 15:58:49 UTC
hm because the name is TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA instead SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA and so on in patch .

Comment 65 Radim Hatlapatka 2014-07-03 16:07:23 UTC
That makes sense, thanks for clarifying.

Comment 66 Kabir Khan 2014-07-03 16:45:45 UTC
As agreed with Radim, I am setting this to MODIFIED for ER9 for the work that has been done so far, which includes my #c55

Comment 69 Arun Babu Neelicattu 2014-07-14 04:04:59 UTC
Replying to Comment 62 (better late than never), I agree with Jean-frederic; if they are unsafe and we do not need to support them, we can avoid defining them. From my standpoint, the minimum requirement should be that the default configuration do not enable weak ciphers. Weather we support/define them for a user to enable is purely up to engineering.

Comment 72 Radim Hatlapatka 2014-07-25 12:40:08 UTC
Verified with EAP 6.3.0.ER10 that cipher-suite="ALL" works and no blocker issues introduced by the patches are found. Non blocker issues are tracked in separate BZs, thereby setting this one to verified

Comment 73 JBoss JIRA Server 2015-09-25 17:35:25 UTC
ehsavoie Hugonnet <ehugonne@redhat.com> updated the status of jira XNIO-229 to Closed


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