On 01/12/2023 14:29, Markus Schlegel wrote:
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.
Tomcat sets that by default in catalina.[sh|bat]
@Mark: You suggested that I shall check the OpenSSL version I use, but I do
not use OpenSSL at all. Just plain Java8 JSSE.
Ack. My point re OpenSSL was to help get the ciphers strong to do what
you wanted it to do.
Mark
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
