You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Markus Schlegel <sc...@gmail.com> on 2023/11/29 10:46:18 UTC
Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
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.
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" ?
Thanks,
Markus Schlegel
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Posted by Markus Schlegel <sc...@gmail.com>.
Using embedded Tomcat, therefore no catalina.bat
Markus
Am Fr., 1. Dez. 2023 um 15:42 Uhr schrieb Mark Thomas <ma...@apache.org>:
> 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 <lo...@kreuser.name>:
> >
> >> Hi
> >>
> >>> Am 29.11.2023 um 11:46 schrieb Markus Schlegel <sc...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Posted by Mark Thomas <ma...@apache.org>.
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 <lo...@kreuser.name>:
>
>> Hi
>>
>>> Am 29.11.2023 um 11:46 schrieb Markus Schlegel <sc...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Posted by Markus Schlegel <sc...@gmail.com>.
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 <lo...@kreuser.name>:
> Hi
>
> > Am 29.11.2023 um 11:46 schrieb Markus Schlegel <sc...@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
>
>
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Posted by lo...@kreuser.name.
Hi
> Am 29.11.2023 um 11:46 schrieb Markus Schlegel <sc...@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
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Posted by Mark Thomas <ma...@apache.org>.
On 29/11/2023 10:46, Markus Schlegel wrote:
<snip/>
> 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.
My test was with the default localhost certificate we use for the Tomcat
unit tests (the name mismatch was ignored). It is also has a 2048 bit
key and uses SHA256withRSA for the signature.
> Anyone which knows if and how the certificate influences the selection of
> possible ciphers?
Yes it does. For TLS < 1.3, the cxipher suite specifies the key exchange
mechanism and that needs to match the server certificate.
> Anyone having similar problems?
> Anyone successful in excluding all ciphers with "CBC" ?
Forget Tomcat for a minute and try this.
First check which OpenSSL version you are using with
openssl version
I get
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
on the machine I am writing this on but its behaviour is consistent with
results I get with other versions.
Then compare the outputs for
openssl ciphers -v 'HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA'
openssl ciphers -v 'HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:-DH'
openssl ciphers -v
'HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:-DH:+ECDH'
openssl ciphers -v 'DH'
openssl ciphers -v 'ECDH'
My main point is that there is no overlap between DH and ECDH. Your
cipher configuration isn't quite doing what you think it is doing.
You should also test
openssl ciphers -v 'CBC'
Can you share (privately if necessary) the host name of your server. I'd
like to compare the SSL Labs results side by side.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org