Bug 1078204
|
Description
Radim Hatlapatka
2014-03-19 11:41:32 UTC
The issue is related to: https://bugzilla.redhat.com/show_bug.cgi?id=1032164 | EAP https connector defaults 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 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>
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
WFLY is not affected by "does not resolve to default" https://github.com/wildfly/wildfly/blob/master/security/subsystem/src/main/java/org/jboss/as/security/SecurityDomainAdd.java#L551 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. Note the related BZ 1032164. 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. Working on implementing openSSL syntax for cipher selection. 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.
Adding link to similar support in XNIO for upstream Emmanuel Hugonnet <ehugonne> updated the status of jira JBWEB-299 to Coding In Progress Providing dev ack on behalf of ehsavioe Created attachment 898220 [details]
Cleaner patch using logging instead of System.out
Created attachment 898235 [details]
Patch to add support for OpenSSL syntax in defining ciphers
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. 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] I am getting the error after openssl request CAMELIA ciphers are patented. I think they shouldn't be in OpenSSL and they should be in JVM that have paid for the patent. 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'"
Created attachment 910709 [details]
keys and certs usable for testing purposes
* 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. 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 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 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"/>
Created attachment 911968 [details]
Patch that fixes the missing aliases and adds some debug messages to help testing
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 Hum, I think it works with AES:+RSA 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. I missed this one :( I've fixed it if this is required. It needs to be either fixed or documented as unsupported case. Created attachment 912705 [details]
For the '+' case I missed
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. Created attachment 912734 [details]
Fix both issues with the +
Created attachment 912744 [details]
Fix both issues with the '+'
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. 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. 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 +++ [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. 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 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 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])); 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 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.
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 Created attachment 914449 [details]
Patch for typo in cipher suite name
Fix for typo in cipher suite name
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? 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? 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 . That makes sense, thanks for clarifying. 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 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. 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 ehsavoie Hugonnet <ehugonne> updated the status of jira XNIO-229 to Closed |