缓解 Logjam / weakdh.org 的正确 JBoss EAP 6.0.1 密码套件配置是什么？
What is the correct JBoss EAP 6.0.1 cipher-suite configuration for mitigation of Logjam / weakdh.org?
由于最近几天 logjam 和网站 https://weakdh.org/（Logjam：Diffie-Hellman 在实践中如何失败）受到的关注，我决定在我的 JBoss 上加强 SSL 配置此处描述的 EAP 6.0.1 系统：
13.2.5。 SSL 连接器参考：https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/SSL_Connector_Reference1.html
此处交叉引用：http://www.coderanch.com/t/613062/JBoss/configuring-SSL-Https-Jboss
我的 standalone.xml 的相关部分包含在下面的混淆形式中：
<connector name="https" protocol="HTTP/1.1" scheme="https"
socket-binding="https" secure="true">
<ssl
key-alias="**********"
password="**********"
certificate-key-file="/var/**********/**********.jks"
protocol="TLSv1.2"
cipher-suite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_SHA,TLS_ECDHE_RSA_WITH_AE_256_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_SHA384,TLS_ECDHE_RSA_WITH_AES_256_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_128_SHA,TLS_DHE_DSS_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_256_SHA256,TLS_DHE_DSS_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_256_SHA"
/>
</connector>
协议限制有效，但据我所知，密码套件属性没有任何效果。我已将列表减少到只有两个套件，但 JBoss 在端口 8443 上返回的列表始终相同。
我已经针对 Qualys SSL Labs 测试了该系统，返回的密码套件列表包括许多未包含在我的列表中的弱密码。
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) WEAK 128
TLS_RSA_WITH_RC4_128_SHA (0x5) WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 768 bits (p: 96, g: 96, Ys: 96) FS INSECURE 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 571 bits (eq. 15360 bits RSA) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 768 bits (p: 96, g: 96, Ys: 96) FS INSECURE 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 571 bits (eq. 15360 bits RSA) FS 112
更新：
我尝试通过 CLI 调整配置，希望它能做一些不同的事情：
/subsystem=web/connector=https/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
然后输出（也对应于新的standalone.xml）：
[standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:read-resource(recursive=true,proxies=false,include-runtime=true,include-defaults=true)
{
"outcome" => "success",
"result" => {
"ca-certificate-file" => undefined,
"ca-certificate-password" => undefined,
"ca-revocation-url" => undefined,
"certificate-file" => undefined,
"certificate-key-file" => "/var/xxxx/xxxx-xx/xxxx.jks",
"cipher-suite" => "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA",
"key-alias" => "xxxx",
"keystore-type" => undefined,
"name" => undefined,
"password" => "****",
"protocol" => "TLSv1.2",
"session-cache-size" => undefined,
"session-timeout" => undefined,
"truststore-type" => undefined,
"verify-client" => "false",
"verify-depth" => undefined
},
"response-headers" => {"process-state" => "reload-required"}
}
但是 nmap 使用这个命令：
nmap -p 8443 -A --script ssh-hostkey,ssh2-enum-algos,sshv1,ssl-cert,ssl-date,ssl-enum-ciphers,ssl-google-cert-catalog,ssl-heartbleed,ssl-known-key,sslv2 xxxx.de
坚持认为其他密码套件仍然有效：
Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-31 09:41 W. Europe Daylight Time
Nmap scan report for xxxx.de (x.x.x.x)
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
8443/tcp open ssl/http Apache Tomcat/Coyote JSP engine 1.1
| ssl-cert: Subject: commonName=xxxx.de
| Issuer: commonName=COMODO RSA Domain Validation Secure Server CA/organizationName=COMODO CA Limited/stateOrProvinceName=Greater Manchester/countryName=GB
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2015-05-27T23:00:00+00:00
| Not valid after: 2016-05-21T22:59:59+00:00
| MD5: 7ac1 b1a9 4fd8 c438 0bce 0e82 bb2a 5e06
|_SHA-1: 9b6e 185c 8598 aec6 7949 e7b1 3183 fc87 637f e86b
| ssl-enum-ciphers:
| TLSv1.0: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - stron
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
| ssl-google-cert-catalog:
|_ No DB entry
Nmap done: 1 IP address (1 host up) scanned in 55.74 seconds
- See more at: https://developer.jboss.org/message/931697#sthash.3ZJZG9PV.dpuf
显然，这里有一些关于这个主题的指导：
https://access.redhat.com/solutions/661193（在 EAP 6 中禁用弱 SSL 密码）
las，我无权访问它，因为 RedHat 的政策似乎将应用程序服务器和 Internet 的安全性置于付费专区之后。叹。
任何人都可以确认这个问题，更好的是，提供解决方案的建议。没有将它放在反向代理（我的计划 B）后面，有人有工作配置吗？谢谢。
由于 JBoss 邮件列表和 Whosebug 工作人员都没有任何反馈，我将此归结为 JBoss 版本中的错误。我已经通过升级到 Wildfly 8.2 并按照提供的说明进行配置来解决它，它按预期工作。
我想这是公认的旧版本服务器中的错误。对于后代，这是 wildfly 的 SSL 侦听器的配置：
<https-listener name="https" socket-binding="https" security-
realm="SSLRealm"
enabled-protocols="TLSv1.2"
enabled-cipher-suites="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, etc."/>
相应的安全领域可能如下所示：
<security-realm name="SSLRealm">
<server-identities>
<ssl >
<keystore
path="/var/mysite/ssl/mysite.jks"
keystore-password="******"
alias="mysite"
/>
</ssl>
</server-identities>
</security-realm>
我们正在使用 jboss-6.1.0 并通过添加
解决了这个问题
SSLHonorCipherOrder="On"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA"
到server.xml，即
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/XXXX"
keystorePass="XXXX" sslProtocol = "TLS"
SSLHonorCipherOrder="On"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA" />
我认为长期解决方案是升级到最新的 JBOSS AS 之一。
得到它与 https 连接器内 ssl 元素的以下属性一起工作：
protocol="TLSv1,TLSv1.1,TLSv1.2"
cipher-suite="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
由于最近几天 logjam 和网站 https://weakdh.org/（Logjam：Diffie-Hellman 在实践中如何失败）受到的关注，我决定在我的 JBoss 上加强 SSL 配置此处描述的 EAP 6.0.1 系统：
13.2.5。 SSL 连接器参考：https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/SSL_Connector_Reference1.html
此处交叉引用：http://www.coderanch.com/t/613062/JBoss/configuring-SSL-Https-Jboss
我的 standalone.xml 的相关部分包含在下面的混淆形式中：
<connector name="https" protocol="HTTP/1.1" scheme="https"
socket-binding="https" secure="true">
<ssl
key-alias="**********"
password="**********"
certificate-key-file="/var/**********/**********.jks"
protocol="TLSv1.2"
cipher-suite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_SHA,TLS_ECDHE_RSA_WITH_AE_256_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_SHA384,TLS_ECDHE_RSA_WITH_AES_256_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_128_SHA,TLS_DHE_DSS_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_256_SHA256,TLS_DHE_DSS_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_256_SHA"
/>
</connector>
协议限制有效，但据我所知，密码套件属性没有任何效果。我已将列表减少到只有两个套件，但 JBoss 在端口 8443 上返回的列表始终相同。 我已经针对 Qualys SSL Labs 测试了该系统，返回的密码套件列表包括许多未包含在我的列表中的弱密码。
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) WEAK 128
TLS_RSA_WITH_RC4_128_SHA (0x5) WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 768 bits (p: 96, g: 96, Ys: 96) FS INSECURE 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 571 bits (eq. 15360 bits RSA) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 768 bits (p: 96, g: 96, Ys: 96) FS INSECURE 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 571 bits (eq. 15360 bits RSA) FS 112
更新： 我尝试通过 CLI 调整配置，希望它能做一些不同的事情：
/subsystem=web/connector=https/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
然后输出（也对应于新的standalone.xml）：
[standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:read-resource(recursive=true,proxies=false,include-runtime=true,include-defaults=true)
{
"outcome" => "success",
"result" => {
"ca-certificate-file" => undefined,
"ca-certificate-password" => undefined,
"ca-revocation-url" => undefined,
"certificate-file" => undefined,
"certificate-key-file" => "/var/xxxx/xxxx-xx/xxxx.jks",
"cipher-suite" => "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA",
"key-alias" => "xxxx",
"keystore-type" => undefined,
"name" => undefined,
"password" => "****",
"protocol" => "TLSv1.2",
"session-cache-size" => undefined,
"session-timeout" => undefined,
"truststore-type" => undefined,
"verify-client" => "false",
"verify-depth" => undefined
},
"response-headers" => {"process-state" => "reload-required"}
}
但是 nmap 使用这个命令：
nmap -p 8443 -A --script ssh-hostkey,ssh2-enum-algos,sshv1,ssl-cert,ssl-date,ssl-enum-ciphers,ssl-google-cert-catalog,ssl-heartbleed,ssl-known-key,sslv2 xxxx.de
坚持认为其他密码套件仍然有效：
Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-31 09:41 W. Europe Daylight Time
Nmap scan report for xxxx.de (x.x.x.x)
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
8443/tcp open ssl/http Apache Tomcat/Coyote JSP engine 1.1
| ssl-cert: Subject: commonName=xxxx.de
| Issuer: commonName=COMODO RSA Domain Validation Secure Server CA/organizationName=COMODO CA Limited/stateOrProvinceName=Greater Manchester/countryName=GB
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2015-05-27T23:00:00+00:00
| Not valid after: 2016-05-21T22:59:59+00:00
| MD5: 7ac1 b1a9 4fd8 c438 0bce 0e82 bb2a 5e06
|_SHA-1: 9b6e 185c 8598 aec6 7949 e7b1 3183 fc87 637f e86b
| ssl-enum-ciphers:
| TLSv1.0: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - stron
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
| ssl-google-cert-catalog:
|_ No DB entry
Nmap done: 1 IP address (1 host up) scanned in 55.74 seconds
- See more at: https://developer.jboss.org/message/931697#sthash.3ZJZG9PV.dpuf
显然，这里有一些关于这个主题的指导： https://access.redhat.com/solutions/661193（在 EAP 6 中禁用弱 SSL 密码） las，我无权访问它，因为 RedHat 的政策似乎将应用程序服务器和 Internet 的安全性置于付费专区之后。叹。
任何人都可以确认这个问题，更好的是，提供解决方案的建议。没有将它放在反向代理（我的计划 B）后面，有人有工作配置吗？谢谢。
由于 JBoss 邮件列表和 Whosebug 工作人员都没有任何反馈，我将此归结为 JBoss 版本中的错误。我已经通过升级到 Wildfly 8.2 并按照提供的说明进行配置来解决它，它按预期工作。
我想这是公认的旧版本服务器中的错误。对于后代，这是 wildfly 的 SSL 侦听器的配置：
<https-listener name="https" socket-binding="https" security-
realm="SSLRealm"
enabled-protocols="TLSv1.2"
enabled-cipher-suites="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, etc."/>
相应的安全领域可能如下所示：
<security-realm name="SSLRealm">
<server-identities>
<ssl >
<keystore
path="/var/mysite/ssl/mysite.jks"
keystore-password="******"
alias="mysite"
/>
</ssl>
</server-identities>
</security-realm>
我们正在使用 jboss-6.1.0 并通过添加
解决了这个问题SSLHonorCipherOrder="On"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA"
到server.xml，即
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/XXXX"
keystorePass="XXXX" sslProtocol = "TLS"
SSLHonorCipherOrder="On"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA" />
我认为长期解决方案是升级到最新的 JBOSS AS 之一。
得到它与 https 连接器内 ssl 元素的以下属性一起工作：
protocol="TLSv1,TLSv1.1,TLSv1.2"
cipher-suite="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"