2

I have two servers that I have been working to configure to use modern ciphers. One is working and the other seems to be reporting mixed results. I'm not sure what the issue is.

Specifically when I check ServerA I get:

The connection is encrypted using AES_256_CBC with HMAC-SHA1 for message authentication and DHE_RSA as the key exchange mechanism

But when I check ServerB I get:

The connection is encrypted using AES_128_GCM and uses DHE_RSA as the key exchange mechanism

ServerA - Linux

tomcat 7.0.37
java 1.7_0_17

ServerB - Linux

tomcat 7.0.54
java 1.8.0_31-b13

I have configured both using the ciphers specified here:

https://blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcat/

The working ServerA has the following server.xml def:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile="conf/keystore.jks" keystorePass="changeit"
ciphers="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" />

The non-working ServerB has the following server.xml def

<Connector port="8443" scheme="https" secure="true"
protocol="HTTP/1.1" SSLEnabled="true" sslProtocol="TLS"
URIEncoding="UTF-8" compression="on" keyPass="changeit" keyAlias="tomcat"
 compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,application/x-javascript,application/javascript,application/json"
useServerCipherSuitesOrder="true"
server="WCC" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1"
ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,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_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA" />

In both cases I have deployed the JCE Unlimited Strength Jurisdiction Policy files for each respective version of Java (7 & 8). I have placed these files in the java lib/security directory.

openssl seems to suggest that 256 bit encryption is available from ServerB:

$ openssl s_client -connect serverb:8443 -cipher "EDH"
CONNECTED(00000003)
depth=0 O = CA, OU = WCC, CN = serverb
verify error:num=18:self signed certificate
verify return:1
depth=0 O = CA, OU = WCC, CN = serverb
verify return:1
---
Certificate chain
0 s:/O=CA/OU=WCC/CN=serverb
i:/O=CA/OU=WCC/CN=serverb
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIB8jCCAVugAwIBAgIEcB/8/TANBgkqhkiG9w0BAQsFADAsMQswCQYDVQQKEwJD
QTEMMAoGA1UECxMDV0NDMQ8wDQYDVQQDEwZvYmVyeW4wHhcNMTUwODE0MDcwNDIx
WhcNMjUwODEzMDcwNDIxWjAsMQswCQYDVQQKEwJDQTEMMAoGA1UECxMDV0NDMQ8w
DQYDVQQDEwZvYmVyeW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMEPswDo
3vBCx5yFW+xWkpOlX0BBp5BNhe7+9kLK94+QUfm4oa7ciNtnxQoYrcLKgq+6kNuf
+Ql5nld5zZTvJzZsR/TSnXxwpih721t3/evKhCysbgr4XhrYP7dAWNwuLHqX7ZF+
UlC6dggumhHLOWuKRK5JbSqw43ERAtrYtvxhAgMBAAGjITAfMB0GA1UdDgQWBBRv
/UnqlwIyPab4qqacR2WTigCxajANBgkqhkiG9w0BAQsFAAOBgQAhbm3TeKK+SlSe
EdP6IFo8fVzCX/Ns11FS4iRvy1jpRAFlKYskDUAF2Mtss6Pike9CD2PxQXIb+Cxb
fvQwK0Cx1KT2/zS9Iy/NUg3rE/L7qTu1lcTxeOV4w7HNivHn1tde3LlLodklAu53
WDy69d351LmoP7K7N9zKf/draeiQfQ==
-----END CERTIFICATE-----
subject=/O=CA/OU=WCC/CN=serverb
issuer=/O=CA/OU=WCC/CN=serverb
---
No client certificate CA names sent
---
SSL handshake has read 1563 bytes and written 463 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher    : DHE-RSA-AES256-GCM-SHA384
Session-ID: 55D8C7DED457280A75F58D473882A9AC2162655E64DB77BA0AC09DDF69870693
Session-ID-ctx: 
Master-Key:      0B0C8BAD22222A3E8B071FF235DF205F0DA6A7BBC800447F8DAFDAFE4141873837A89D51A92181478BC53038094475DD
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1440270308
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---

Any ideas why I can't get serverB to use 256 bit encryption?

screwed
  • 21
  • 3
  • try adding `clientAuth="false"` to the b server config. At least that is missing from the a server config. – Henrik Pingel Aug 23 '15 at 07:07
  • Ok, I have been successful in getting serverB to use 256 bit encryption but only if I remove all references to the AES128 ciphers. So I guess the question now is, why isn't it picking the stronger cipher when both 128 and 256 are specified? Should this be a new separate question? – screwed Aug 24 '15 at 04:35
  • u can't have gotten DHE_RSA for serverA with the configuration shown, and shouldn't have for serverB with any sane client. Note Java7 server uses 768-bit params for DHE which is now breakable, and Java8 defaults to 1024-bit which may be and is unacceptable under standards like NIST 800-57. ECDHE in Java7 or 8 prefers P-256 which is hugely stronger. And the cert you show is RSA-1024 which is unacceptable now and will probably start being rejected soon. OTOH AES256 offers no security benefit at all over AES128; allocating your time to that is reducing your security, and probably performance. – dave_thompson_085 Aug 26 '15 at 06:07

1 Answers1

0

I found this which seems to address my question regarding cipher selection.

https://stackoverflow.com/questions/10295446/how-does-java-picks-the-strongest-cipher-to-use-in-jsse

I think I will have to wait until I implement Tomcat 8 to see what effect this setting has: useServerCipherSuitesOrder="true"

Community
  • 1
screwed
  • 21
  • 3