什么是用于缓解Logjam / weakdh.org的正确的JBoss EAP 6.0.1密码套件配置？
由于最近几天logjam和网站https://weakdh.org/（Logjam：Diffie-Hellman如何在实践中失败）的关注，我决定强化我的JBoss EAP 6.0.1系统上的SSL配置这里描述：
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的相关部分包含在下面的混淆forms中：
协议限制正在起作用，但据我所知，密码套件属性没有效果。 我已将列表缩减为仅两个套件，但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 (xxxx) 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密码）唉，我无法访问它，因为RedHat的策略似乎会带来安全性应用服务器和互联网一般在付费墙后面。 叹。
任何人都可以确认这个问题，更好的是，提供解决方案的建议。 如果没有将其置于反向代理（我的计划B）之后，是否有人有工作配置？ 谢谢。
参考： https ： //developer.jboss.org/message/931697
由于JBoss邮件列表和Stackoverflow工作人员都没有任何反馈意见，因此我将这个问题归结为JBoss版本中的一个错误。 我通过升级到Wildfly 8.2并使用提供的说明进行配置来解决它，它按预期工作。
我想这是一个臭名昭着的，不可否认的是旧版本的服务器。 对于后代，这是wildfly的SSL侦听器的配置：
相应的安全领域可能如下所示：
我们正在使用jboss-6.1.0并通过添加解决了这个问题
SSLHonorCipherOrder="On" ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA"
到server.xml ，即
我认为长期解决方案是升级到最新的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"