title: What is the correct JBoss EAP 6.0.1 cipher-suite configuration for mitigation of Logjam / weakdh.org?
body: <p>Because of the attention that logjam and the website <a href="https://weakdh.org/" rel="nofollow">https://weakdh.org/</a> (Logjam: How Diffie-Hellman Fails in Practice) has received in recent days, I decided to harden the SSL configuration on my JBoss EAP 6.0.1 system as described here:</p>
  
  <p>13.2.5. SSL Connector Reference: <a href="https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/SSL_Connector_Reference1.html" rel="nofollow">https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/SSL_Connector_Reference1.html</a></p>
  
  <p>Cross referenced to here: <a href="http://www.coderanch.com/t/613062/JBoss/configuring-SSL-Https-Jboss" rel="nofollow">http://www.coderanch.com/t/613062/JBoss/configuring-SSL-Https-Jboss</a> </p>
  
  <p>The relevant portion of my standalone.xml is included in obfuscated form below:</p>
  
  <pre>
       &lt;connector name=&quot;https&quot; protocol=&quot;HTTP/1.1&quot; scheme=&quot;https&quot; 
      socket-binding=&quot;https&quot; secure=&quot;true&quot;&gt;  
      &lt;ssl  
       key-alias=&quot;**********&quot;  
       password=&quot;**********&quot;  
       certificate-key-file=&quot;/var/**********/**********.jks&quot;  
       protocol=&quot;TLSv1.2&quot;  
       cipher-suite=&quot;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&quot;  
       /&gt;  
      &lt;/connector&gt; 
  </pre>
  
  <p>The protocol restriction is working but the cipher-suite attribute has, as far as I can tell, no effect. I have reduced the list down to just two suites but the list returned by JBoss on port 8443 is always the same. 
  I have tested the system against Qualys SSL Labs and the list of cipher suites returned includes numerous weak of ciphers not included in my list.</p>
  
  <pre><code> 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
  </code></pre>
  
  <p><strong>Update</strong>:
  I tried adjusting the configuration via the CLI in the hope it might do something different:</p>
  
  <pre><code> /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")
  </code></pre>
  
  <p>which then outputs (corresponds also to the new standalone.xml):</p>
  
  <pre><code> [standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:read-resource(recursive=true,proxies=false,include-runtime=true,include-defaults=true)
   {
        "outcome" =&gt; "success",
        "result" =&gt; {
             "ca-certificate-file" =&gt; undefined,
             "ca-certificate-password" =&gt; undefined,
             "ca-revocation-url" =&gt; undefined,
             "certificate-file" =&gt; undefined,
             "certificate-key-file" =&gt; "/var/xxxx/xxxx-xx/xxxx.jks",
             "cipher-suite" =&gt; "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA",
             "key-alias" =&gt; "xxxx",
             "keystore-type" =&gt; undefined,
             "name" =&gt; undefined,
             "password" =&gt; "****",
             "protocol" =&gt; "TLSv1.2",
             "session-cache-size" =&gt; undefined,
             "session-timeout" =&gt; undefined,
             "truststore-type" =&gt; undefined,
             "verify-client" =&gt; "false",
             "verify-depth" =&gt; undefined
        },
        "response-headers" =&gt; {"process-state" =&gt; "reload-required"}
   }
  </code></pre>
  
  <p>but nmap using this command:</p>
  
  <pre><code> 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
  </code></pre>
  
  <p>insists that the other cipher-suites are still active:</p>
  
  <pre><code> 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
  </code></pre>
  
  <p>Apparently, there is some guidance on this topic here:
  <a href="https://access.redhat.com/solutions/661193" rel="nofollow">https://access.redhat.com/solutions/661193</a> (Disable weak SSL ciphers in EAP 6)
  Alas, I have no access to that, as RedHat's policy would seem to put security of the application server and the Internet in general behind a paywall. Sigh. </p>
  
  <p>Can anyone confirm this issue and better yet, offer advice for a resolution. Short of putting it behind a reverse proxy (my plan B), does anyone have a working configuration? Thanks. </p>
  
  <p>Ref: <a href="https://developer.jboss.org/message/931697" rel="nofollow">https://developer.jboss.org/message/931697</a></p>