Hi Peter, Thank you for your hint about "-Djdk.tls.ephemeralDHKeySize=2048". I indeed did not knew that this option exists. When I enable it, I get Grad "A" from SSLLabs while it still lists 8 weak ciphers out of 12.
Because I get to grade "A" with this setting, I can indeed use the default ciphers settings from Tomcat again and as a consequence, the Warning will not anymore appear in the log. Maybe Mark had that setting active too while doing his ssllab tests. This would explain the difference in the results. @Mark: You suggested that I shall check the OpenSSL version I use, but I do not use OpenSSL at all. Just plain Java8 JSSE. Kind regards and thanks a lot for your valuable help, Markus Schlegel Am Fr., 1. Dez. 2023 um 14:09 Uhr schrieb <l...@kreuser.name>: > Hi > > > Am 29.11.2023 um 11:46 schrieb Markus Schlegel <sch...@gmail.com>: > > > > Hi, > > This is a continuation of the discussion taken below > > https://bz.apache.org/bugzilla/show_bug.cgi?id=67628 where I asked about > > the following warning which appears in our log: > > > > (29.11.2023 09:53:14 org.apache.tomcat.util.net.SSLUtilBase getEnabled > > WARNING T-19): Tomcat interprets the [ciphers] attribute in a manner > > consistent with the latest OpenSSL development branch. Some of the > > specified [ciphers] are not supported by the configured SSL engine for > this > > connector (which may use JSSE or an older OpenSSL version) and have been > > skipped: [[TLS_DHE_PSK_WITH_AES_256_CCM, (... I am excluding 60 entries > > here...), TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256]] > > > > After some discussion in the ASF bugzilla, Mark asked to move the > > discussion about the default ciphers configuration into this users > > mailing list. > > > > We explicitly set the ciphers configuration since the default config > > which comes with Tomcat still includes the (normal) Diffie-Helman key > > exchange algorithm which are considered to be insecure (but not the > > ECDH's!). See https://weakdh.org/ for information about this. > > > > We can't turn off that warning without getting other drawbacks as long > > as we use our custom ciphers configuration, which led "warnOnSkip" > > being set to true in the respective code section. > > Those skipped ciphers are of no interest for us or our customers since > > they appear only because Tomcat - as of my understanding - uses the > > ciphers-set from OpenSSL to build the complete list of theoretically > > available ciphers. > > > > There is nothing wrong with our configuration, but having that warning > > in the log will cause each and every customer asking us why this > > warning ist there - since they will fear a configuration problem. > > > > One question now is, if the default configuration of the ciphers in > > Tomcat 8.5.96 is still save or not. > > > > I have re-run https://www.ssllabs.com/ssltest against our server setup. > > With the Tomcat default ciphers configuration > > "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA" I get grade "B" > > because of the weak key exchange algorithm using DH. It lists 10 weak > > ciphers out of 12. > > > Why are you saying that you get a weak Keyexchange with DH? That is not > per se the case. DH is still valid. > > Did you set -Djdk.tls.ephemeralDHKeySize=2048 as CATALINA_OPTS ? > > > If I run it with our configuration, which adds ":-DH:+ECDH", I get > > Grade "A" with 4 weak ciphers out of 6. > > > > Changing the config to add ":-CBC" to the default config as suggested > > by Mark in bugzilla does not have any effect. Still Grade B, 10 weak > > out of 12. It seems to me that -CBC might not be a valid option at > > all? > > > > Mark got different results when he run the ssllabs tests. That might > > be caused by different TLS certificates used? I am using a certificate > > created with a RSA-2048bits Key and SHA256withRSA signature algorithm. > > No clue if this causes any difference to Mark's setup. > > > > Anyone which knows if and how the certificate influences the selection of > > possible ciphers? > > > > Anyone having similar problems? > > Anyone successful in excluding all ciphers with "CBC" ? > > > > In my case I was only successful to get the ciphers right by setting them > manually: > > > ciphers="TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" > > The result is A(+) and TLS is supported from Java 8, IE 11, iOS12.2, > Android 6, Chrome 79, Firefox 66, Safari 13.0, which seems to be sufficient > to me. > > Maybe I could get even away from DH from the result of the client > simulations. In the end it's up to you if you prioritize 128 or 256bit > ciphers. BTW I use testssl.sh for local tests (and non 443 ports). > > From what I found elsewhere, ECDH+AES256:ECDH+AES128 are the culprits for > the CBCs. > > Regards > > Peter > > > Thanks, > > Markus Schlegel > >
