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
