Ich habe zwei Server, die ich für die Verwendung moderner Chiffren konfiguriert habe. Einer funktioniert, der andere scheint gemischte Ergebnisse zu melden. Ich bin mir nicht sicher, wo das Problem liegt.
Insbesondere wenn ich ServerA überprüfe, erhalte ich:
Die Verbindung wird mit AES_256_CBC mit HMAC-SHA1 zur Nachrichtenauthentifizierung und DHE_RSA als Schlüsselaustauschmechanismus verschlüsselt.
Aber wenn ich ServerB überprüfe, erhalte ich:
Die Verbindung wird mit AES_128_GCM verschlüsselt und verwendet DHE_RSA als Schlüsselaustauschmechanismus
ServerA - Linux
tomcat 7.0.37
java 1.7_0_17
ServerB - Linux
tomcat 7.0.54
java 1.8.0_31-b13
Ich habe beide mit den hier angegebenen Chiffren konfiguriert:
https://blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcat/
Der funktionierende ServerA hat die folgende 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" />
Der nicht funktionierende ServerB hat die folgende 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 beiden Fällen habe ich die JCE Unlimited Strength Jurisdiction Policy-Dateien für die jeweilige Java-Version (7 und 8) bereitgestellt. Ich habe diese Dateien im Verzeichnis java lib/security abgelegt.
openssl scheint darauf hinzudeuten, dass 256-Bit-Verschlüsselung von ServerB verfügbar ist:
$ 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)
---
Irgendwelche Ideen, warum ich Server B nicht dazu bringen kann, die 256-Bit-Verschlüsselung zu verwenden?
Antwort1
Ich habe das hier gefunden, was meine Frage zur Chiffreauswahl zu beantworten scheint.
Ich denke, ich muss warten, bis ich Tomcat 8 implementiere, um zu sehen, welche Auswirkungen diese Einstellung hat: useServerCipherSuitesOrder="true"