What's the correct JBoss EAP 6.0.1 encryption configuration to mitigate Logjam / weakdh.org?
Due to the attention that the logjam and website https://weakdh.org/ (Logjam: How Diffie-Hellman Fails in Practice) have gotten in recent days, I decided to simplify the SSL configuration on my JBoss EAP 6.0.1 system. as described here:
13.2.5. SSL Connector Link: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/SSL_Connector_Reference1.html
Cross reference here: http://www.coderanch.com/t/613062/JBoss/configuring-SSL-Https-Jboss
The relevant part of my standalone.xml is included in the obfuscation form below:
<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>
The protocol limitation works, but the cipher suite attribute is not affected as far as I can tell. I've reduced the list to two sets, but the list returned by JBoss on port 8443 is always the same. I tested the system against Qualys SSL Labs and the list of cipher suites returned includes many weak ciphers not included in my list.
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
Update : I tried to tweak the config via the CLI in the hopes that it might do something different:
/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")
which then outputs (matches the new standalone.xml too):
[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"}
}
but nmap with this command:
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
insists that the rest of the cipher packets are still active:
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
Apparently there are a few guidelines on this topic here: https://access.redhat.com/solutions/661193 (Disable weak SSL ciphers in EAP 6) Alas, I don't have access to this as the RedHat policy seems to be put the security of the application server and the Internet as a whole for a fee. Sigh.
Can anyone confirm this issue and better yet, suggest advice for a solution. If you don't have a reverse proxy (my plan B), does anyone have a working configuration? Thank you.
source to share
Since there is no feedback on either the JBoss mailing list or the Stackoverflow team, I prevented this bug in this version of JBoss. I resolved it by upgrading to Wildfly 8.2 and tweaking with the instructions provided and it works as expected.
I am guessing that this was a bug in an admittedly older version of the server. For posterity, this is the wildfly SSL listener config:
<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."/>
The relevant security area might look like this:
<security-realm name="SSLRealm">
<server-identities>
<ssl >
<keystore
path="/var/mysite/ssl/mysite.jks"
keystore-password="******"
alias="mysite"
/>
</ssl>
</server-identities>
</security-realm>
source to share
We are using jboss-6.1.0 and solved the problem by adding
SSLHonorCipherOrder="On"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA"
before server.xml , i.e.
<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" />
I think the long term solution would be to upgrade to one of the latest JBOSS AS.
source to share
Got working with the following attributes for an ssl element inside an https connector:
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"
source to share