Re: Weird CSRF prevention behavior
Well, one thing that could be wrong is that Log4j2 does not have FINE or
FINEST levels. It does have TRACE. If that does not fix things, you could
always change tour log.trace to log.error if you only care about debugging
the original issue.
pe 1. jouluk. 2023 klo 22.28 Christopher Schultz (
ch...@christopherschultz.net) kirjoitti:
> All,
>
> I'm experimenting with the CsrfPreventionFilter in Tomcat 8.5. I've had
> issues with it in the past so I haven't actually enabled it in any of my
> applications, but I'm sufficiently motivated at this point to get it done.
>
> My "application" is actually split up into two applications, each
> running in a separate JVM but in the same URL space. I have a
> reverse-proxy that figures this all out and it's been working for years.
> I don't see why this wouldn't work.
>
> I have enabled CSRF prevention in Application A which is the "primary
> application" and the secondary application (Application B) is capable of
> mimicking/proxying the csrf token back to Application A.
>
> Application B has a feature where we present a web form to the user.
> It's fairly simple (paraphrasing):
>
>
>
>
>
> When I submit this form, I get an HTTP 403 response. Our application
> doesn't send 403 responses. When I remove the CsrfPreventionFilter from
> the configuration) by commenting-out the in
> WEB-INF/web.xml, I do not get the 403 response and the form submission
> is successful. I'm sure that the CSRF token is *NOT* in the POST
> request: the browser shows me what is sent and it's not there. I have
> hacked the form and added the token, submitted it, and it /works/.
>
> But this is an HTTP POST and should be ignored by the filter.
>
> So I figure I'll enable logging and see what's happening. There isn't
> much logging in CsrfPreventionFilter, so I add this line to the
> beginning of the skipNonceCheck method:
>
> log.trace("skipNonceCheck(" + request.getMethod() + " " +
> request.getRequestURI() + ")");
>
> I build-from-source and launch my custom-build Tomcat with my
> application in it. No logging. Oh, right... logging.properties. So I add
> this to my conf/logging.properties file:
>
> org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST
>
> To be sure there's no funny business, I use "catalina.sh run" and wait
> for the console log to settle down. I make a few requests. No logs. Hmm.
> Oh, the ConsoleAppender is set to FINE and not FINEST.
>
> java.util.logging.ConsoleHandler.level = FINEST
>
> Done. CTRL-C, catalina.sh run. Make some requests.
>
> Nothing. Okay maybe the Filter is just ignoring these for some
> reason. So I add this line to the beginning of doFilter, before anything
> else happens:
>
> log.trace("doFilter(" + request + ")");
>
> Re-build. CTRL-C. catalina.sh run. Make some requests.
>
> Nothing.
>
> The Filter is absolutely running. If I reload a page, the csrf tokens on
> all the links are changing. What's going on?
>
> You'd think a Tomcat committer could figure out how to make logging work.
>
> My application is using log4j2, but that library is only used by the
> application and the JAR file is in WEB-INF/lib/. I wouldn't expect that
> it would interfere with server-level logging.
>
> Any ideas? About EITHER issue? If anyone can help with logging, maybe I
> can figure out what's happening in the Filter. If you have any
> suggestions about the Filter, I'm al ears. HTTP POST should not be
> prohibited unless I'm reading both the code and the CSRF specs incorrectly.
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Weird CSRF prevention behavior
All,
I'm experimenting with the CsrfPreventionFilter in Tomcat 8.5. I've had
issues with it in the past so I haven't actually enabled it in any of my
applications, but I'm sufficiently motivated at this point to get it done.
My "application" is actually split up into two applications, each
running in a separate JVM but in the same URL space. I have a
reverse-proxy that figures this all out and it's been working for years.
I don't see why this wouldn't work.
I have enabled CSRF prevention in Application A which is the "primary
application" and the secondary application (Application B) is capable of
mimicking/proxying the csrf token back to Application A.
Application B has a feature where we present a web form to the user.
It's fairly simple (paraphrasing):
When I submit this form, I get an HTTP 403 response. Our application
doesn't send 403 responses. When I remove the CsrfPreventionFilter from
the configuration) by commenting-out the in
WEB-INF/web.xml, I do not get the 403 response and the form submission
is successful. I'm sure that the CSRF token is *NOT* in the POST
request: the browser shows me what is sent and it's not there. I have
hacked the form and added the token, submitted it, and it /works/.
But this is an HTTP POST and should be ignored by the filter.
So I figure I'll enable logging and see what's happening. There isn't
much logging in CsrfPreventionFilter, so I add this line to the
beginning of the skipNonceCheck method:
log.trace("skipNonceCheck(" + request.getMethod() + " " +
request.getRequestURI() + ")");
I build-from-source and launch my custom-build Tomcat with my
application in it. No logging. Oh, right... logging.properties. So I add
this to my conf/logging.properties file:
org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST
To be sure there's no funny business, I use "catalina.sh run" and wait
for the console log to settle down. I make a few requests. No logs. Hmm.
Oh, the ConsoleAppender is set to FINE and not FINEST.
java.util.logging.ConsoleHandler.level = FINEST
Done. CTRL-C, catalina.sh run. Make some requests.
Nothing. Okay maybe the Filter is just ignoring these for some
reason. So I add this line to the beginning of doFilter, before anything
else happens:
log.trace("doFilter(" + request + ")");
Re-build. CTRL-C. catalina.sh run. Make some requests.
Nothing.
The Filter is absolutely running. If I reload a page, the csrf tokens on
all the links are changing. What's going on?
You'd think a Tomcat committer could figure out how to make logging work.
My application is using log4j2, but that library is only used by the
application and the JAR file is in WEB-INF/lib/. I wouldn't expect that
it would interfere with server-level logging.
Any ideas? About EITHER issue? If anyone can help with logging, maybe I
can figure out what's happening in the Filter. If you have any
suggestions about the Filter, I'm al ears. HTTP POST should not be
prohibited unless I'm reading both the code and the CSRF specs incorrectly.
Thanks,
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 build from scratch
Aditya, On 12/1/23 12:48, Aditya Shastri wrote: Yes. Equally importantly it also ensures that the code is compiled against the Java 8 API. > Makes sense! It is used for property replacement in the documentation for the minimum Java version required at runtime. We do it this way so the documentation source files can be the same for all Tomcat versions with the correct minimum version being inserted via this property. It makes it a lot easier when we start a new major version as we only have to change the minimum version in one place rather than searching through the documentation to find all the places that reference the minimum version. That only happens during the `ant release` step? Doesn't really affect a regular compile from source situation? It actually happens when building the documentation. It has nothing to do with the source, which may be confusing if you are just reading the Ant property names. We probably could have chosen a better name for that property, or at least written a bit of documentation for it to make it clear. -chris On Fri, Dec 1, 2023, 3:41 AM Mark Thomas wrote: On 30/11/2023 23:38, Aditya Shastri wrote: Thanks for the response Adwait. My ant skills are lacking. Does the minimum bytecode definition come from this line? Yes. Equally importantly it also ensures that the code is compiled against the Java 8 API. What does this line do? It is used for property replacement in the documentation for the minimum Java version required at runtime. We do it this way so the documentation source files can be the same for all Tomcat versions with the correct minimum version being inserted via this property. It makes it a lot easier when we start a new major version as we only have to change the minimum version in one place rather than searching through the documentation to find all the places that reference the minimum version. Mark On Thu, Nov 30, 2023 at 6:10 PM Adwait Kumar Singh wrote: Yes, JDK17 can produce JDK8 bytecode, in fact that's what Tomcat does. On Thu, Nov 30, 2023 at 2:35 PM Aditya Shastri < aditya.shastri5...@gmail.com> wrote: Hello, We build our own Tomcat 9 binaries from scratch (grab the tag from https://github.com/apache/tomcat) and call ant (with java8) to build it. Starting with 9.0.83, our pipelines are failing with the error build.xml:113: Java version 17 or newer is required (1.8.0_381 is installed) The apps we have are only certified on Java 8 and it would take a bit of work to get it to Java 17. My question is if I build the binaries with Java 17, can I still use it with Java 8? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 build from scratch
> Yes. Equally importantly it also ensures that the code is compiled against the Java 8 API. Makes sense! > It is used for property replacement in the documentation for the minimum Java version required at runtime. We do it this way so the documentation source files can be the same for all Tomcat versions with the correct minimum version being inserted via this property. It makes it a lot easier when we start a new major version as we only have to change the minimum version in one place rather than searching through the documentation to find all the places that reference the minimum version. That only happens during the `ant release` step? Doesn't really affect a regular compile from source situation? Thank you for your response! On Fri, Dec 1, 2023, 3:41 AM Mark Thomas wrote: > On 30/11/2023 23:38, Aditya Shastri wrote: > > Thanks for the response Adwait. > > > > My ant skills are lacking. Does the minimum bytecode definition come > > from this line? > > > > Yes. Equally importantly it also ensures that the code is compiled > against the Java 8 API. > > > What does this line do? > > > > It is used for property replacement in the documentation for the minimum > Java version required at runtime. We do it this way so the documentation > source files can be the same for all Tomcat versions with the correct > minimum version being inserted via this property. It makes it a lot > easier when we start a new major version as we only have to change the > minimum version in one place rather than searching through the > documentation to find all the places that reference the minimum version. > > Mark > > > > > On Thu, Nov 30, 2023 at 6:10 PM Adwait Kumar Singh > wrote: > >> > >> Yes, JDK17 can produce JDK8 bytecode, in fact that's what Tomcat does. > >> > >> On Thu, Nov 30, 2023 at 2:35 PM Aditya Shastri < > aditya.shastri5...@gmail.com> > >> wrote: > >> > >>> Hello, > >>> > >>> We build our own Tomcat 9 binaries from scratch (grab the tag from > >>> https://github.com/apache/tomcat) and call ant (with java8) to build > >>> it. > >>> > >>> Starting with 9.0.83, our pipelines are failing with the error > >>> build.xml:113: Java version 17 or newer is required (1.8.0_381 is > >>> installed) > >>> > >>> The apps we have are only certified on Java 8 and it would take a bit > >>> of work to get it to Java 17. > >>> > >>> My question is if I build the binaries with Java 17, can I still use > >>> it with Java 8? > >>> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>> > >>> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Peter, On 12/1/23 10:12, l...@kreuser.name wrote: Chuck, Am 01.12.2023 um 16:07 schrieb Chuck Caldarale : On Dec 1, 2023, at 02:27, Manak Bisht wrote: Hi, I am trying to implement non-sticky session replication using Delta Manager with static membership. The nodes are across two different machines. I am unable to discover members in the cluster with the following logs on both machines - org.apache.catalina.ha.session.DeltaManager.startInternal Register manager localhost# to cluster element Engine with name Catalina org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at localhost# org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [localhost#]: skipping state transfer. No members active in cluster group. Please find the cluster settings (inside the * *tag) below. I have also added the * *tag to the *web.xml *files. *Node_1* . . . I’m not a clustering expert, but perhaps the address value needs to be an IP address accessible to the other machine in the cluster. The above 127.0.0.1 (localhost) would appear to limit each receiver to the machine it’s running on. The second node has the same issue. NICE find! -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Manak, On 12/1/23 03:27, Manak Bisht wrote: Hi, I am trying to implement non-sticky session replication using Delta Manager with static membership. The nodes are across two different machines. This isn't really relevant to your issue, but I would *always* recommend enabling stickiness. Why? I'll tell you. The DeltaManager (and really any clustered Manager) works by listening for HttpSessionAttributeListener events and, after a request has completed, distributing the changes to the session across all other cluster members. You can almost think of it like an RDBMS transaction: INSERT, UPDATE, DELETE... then COMMIT. Not until the COMMIT will the rest of the cluster see the changes. Your browser will happily make multiple simultaneous requests to a web service, so there can be multiple requests in flight at any one time. If these go to different servers in your cluster (because you have disabled stickiness), then two requests can be modifying the state of your users' sessions separately on any number of servers simultaneously, and independently of each other. You cannot predict which request will go where and when the replication from any source node will occur and take effect on any destination node. The situation is sufficiently chaotic that something odd like this may affect a user: 1. They are looking at a view in your application 2. They choose a "change language" option that switches from e.g. English to e.g. French 3. The request from (2) above goes to Node X, and the session's locale changes from "en" to "fr", and the response includes a redirect e.g. "back to the same page you were just looking at" 4. The client follows the redirect, but hits Node Y in your cluster, which has not yet received the session-replication-event which includes the updated locale setting. The response is shown in English, because that's the value still in the user's session. 5. The user files a bug report, stating "When I changed language, the change didn't take effect until the SECOND request". 6. Nobody can replicate the problem in dev/testing because either the dev/test cluster is too fast or you don't bother with clustered sessions in dev/test. If you enable stickiness, all requests will be delivered to the same server and the above situation is extraordinarily unlikely. The only time your user has to switch servers is if their primary node fails for some reason. When failover occurs, Strange Things are bound to happen for a variety of reasons, but those situations are unusual. If you disable stickiness, those Weird Things can literally happen with /every request/. If you have a good reason to disable stickness, I'd love to hear the reasoning. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Chuck, > Am 01.12.2023 um 16:07 schrieb Chuck Caldarale : > > >> On Dec 1, 2023, at 02:27, Manak Bisht wrote: >> >> Hi, I am trying to implement non-sticky session replication using Delta >> Manager with static membership. The nodes are across two different >> machines. I am unable to discover members in the cluster with the following >> logs on both machines - >> >> org.apache.catalina.ha.session.DeltaManager.startInternal Register manager >> localhost# to cluster element Engine with name Catalina >> org.apache.catalina.ha.session.DeltaManager.startInternal Starting >> clustering manager at localhost# >> org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager >> [localhost#]: skipping state transfer. No members active in cluster group. >> >> Please find the cluster settings (inside the * *tag) below. I have >> also added the * *tag to the *web.xml *files. >> >> *Node_1* > > . . . > >> >> > className="org.apache.catalina.tribes.transport.nio.NioReceiver" >> address="127.0.0.1" >> port="8090" >> autoBind="0" >> maxThreads="6”/> > > > I’m not a clustering expert, but perhaps the address value needs to be an IP > address accessible to the other machine in the cluster. The above 127.0.0.1 > (localhost) would appear to limit each receiver to the machine it’s running > on. > > The second node has the same issue. NICE find! > > - Chuck > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
> On Dec 1, 2023, at 02:27, Manak Bisht wrote: > > Hi, I am trying to implement non-sticky session replication using Delta > Manager with static membership. The nodes are across two different > machines. I am unable to discover members in the cluster with the following > logs on both machines - > > org.apache.catalina.ha.session.DeltaManager.startInternal Register manager > localhost# to cluster element Engine with name Catalina > org.apache.catalina.ha.session.DeltaManager.startInternal Starting > clustering manager at localhost# > org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager > [localhost#]: skipping state transfer. No members active in cluster group. > > Please find the cluster settings (inside the * *tag) below. I have > also added the * *tag to the *web.xml *files. > > *Node_1* . . . > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" >address="127.0.0.1" >port="8090" >autoBind="0" >maxThreads="6”/> I’m not a clustering expert, but perhaps the address value needs to be an IP address accessible to the other machine in the cluster. The above 127.0.0.1 (localhost) would appear to limit each receiver to the machine it’s running on. The second node has the same issue. - Chuck
Re: Tracking keep alive connections
Daniel, On 12/1/23 00:09, Daniel Andres Pelaez Lopez wrote: Christopher, So... when a connection is established, save the current timestamp on the connection. When it closes, take the delta of the start-of-connection and end-of-connection, and add it to a bounded queue (say, 100? 1000?) of most-recent-connection-lifetimes. Any time you request the average from the bean, it does the math on the whole set? That makes totally sense, any way to listen those events in Tomcat? Not really. It's probably something that would have to be implemented internally to Tomcat. The trick is iterating over a list of samples while that list is being mutated. I was just trying to understand what you were looking for. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Using embedded Tomcat, therefore no catalina.bat Markus Am Fr., 1. Dez. 2023 um 15:42 Uhr schrieb Mark Thomas : > 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 : > > > >> Hi > >> > >>> Am 29.11.2023 um 11:46 schrieb Markus Schlegel : > >>> > >>> 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: > >> > >> > >> >
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
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 : Hi Am 29.11.2023 um 11:46 schrieb Markus Schlegel : 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)
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 : > Hi > > > Am 29.11.2023 um 11:46 schrieb Markus Schlegel : > > > > 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,
Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)
Hi > Am 29.11.2023 um 11:46 schrieb Markus Schlegel : > > 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: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Sorry, I forgot to mention, but I am using Tomcat 8.5 Sincerely Manak Bisht On Fri, Dec 1, 2023 at 3:40 PM Manak Bisht wrote: > Thanks for the reply Mark. > > The channelStartOptions setting is from the documentation > https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html > *"To start a channel without multicasting, you would want to use the value > Channel.SND_RX_SEQ | Channel.SND_TX_SEQ that equals to 3. "* > > This configuration is working fine when both nodes are on the same local > machine (with different ports). It's on the multi machine setup that I am > facing a problem. Pinging the other machines is fine from both nodes, so it > should not be a networking issue. > > Also, the documentation also says that the *distributable *tag is > deprecated and ignored since Tomcat 8 ( > https://tomcat.apache.org/migration-9) > *"The distributable attribute has been deprecated in 8.0 and specified > value is ignored."* > > Sincerely > Manak Bisht > > On Fri, Dec 1, 2023 at 2:21 PM Mark Thomas wrote: > >> On 01/12/2023 08:27, Manak Bisht wrote: >> > Hi, I am trying to implement non-sticky session replication using Delta >> > Manager with static membership. The nodes are across two different >> > machines. I am unable to discover members in the cluster with the >> following >> > logs on both machines - >> > >> > org.apache.catalina.ha.session.DeltaManager.startInternal Register >> manager >> > localhost# to cluster element Engine with name Catalina >> > org.apache.catalina.ha.session.DeltaManager.startInternal Starting >> > clustering manager at localhost# >> > org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions >> Manager >> > [localhost#]: skipping state transfer. No members active in cluster >> group. >> > >> > Please find the cluster settings (inside the * *tag) below. I >> have >> > also added the * *tag to the *web.xml *files. >> > >> > *Node_1* >> > > > channelSendOptions="6" channelStartOptions="3"> >> >> Why channelStartOptions=3 ? I think this shoudl use the default. >> >> > > > expireSessionsOnShutdown="false" >> > notifyListenersOnReplication="true"/> >> >> Minor point but I try not to define values that are using the defaults >> so I cam more easily see the 'interesting' settings. >> >> >> >> > What am I doing wrong here? Any help would be greatly appreciated. >> >> Nothing else jumps out at me immediately. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Thanks for the reply Mark. The channelStartOptions setting is from the documentation https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html *"To start a channel without multicasting, you would want to use the value Channel.SND_RX_SEQ | Channel.SND_TX_SEQ that equals to 3. "* This configuration is working fine when both nodes are on the same local machine (with different ports). It's on the multi machine setup that I am facing a problem. Pinging the other machines is fine from both nodes, so it should not be a networking issue. Also, the documentation also says that the *distributable *tag is deprecated and ignored since Tomcat 8 (https://tomcat.apache.org/migration-9 ) *"The distributable attribute has been deprecated in 8.0 and specified value is ignored."* Sincerely Manak Bisht On Fri, Dec 1, 2023 at 2:21 PM Mark Thomas wrote: > On 01/12/2023 08:27, Manak Bisht wrote: > > Hi, I am trying to implement non-sticky session replication using Delta > > Manager with static membership. The nodes are across two different > > machines. I am unable to discover members in the cluster with the > following > > logs on both machines - > > > > org.apache.catalina.ha.session.DeltaManager.startInternal Register > manager > > localhost# to cluster element Engine with name Catalina > > org.apache.catalina.ha.session.DeltaManager.startInternal Starting > > clustering manager at localhost# > > org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager > > [localhost#]: skipping state transfer. No members active in cluster > group. > > > > Please find the cluster settings (inside the * *tag) below. I > have > > also added the * *tag to the *web.xml *files. > > > > *Node_1* > > > channelSendOptions="6" channelStartOptions="3"> > > Why channelStartOptions=3 ? I think this shoudl use the default. > > > > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true"/> > > Minor point but I try not to define values that are using the defaults > so I cam more easily see the 'interesting' settings. > > > > > What am I doing wrong here? Any help would be greatly appreciated. > > Nothing else jumps out at me immediately. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
On 01/12/2023 08:27, Manak Bisht wrote: Hi, I am trying to implement non-sticky session replication using Delta Manager with static membership. The nodes are across two different machines. I am unable to discover members in the cluster with the following logs on both machines - org.apache.catalina.ha.session.DeltaManager.startInternal Register manager localhost# to cluster element Engine with name Catalina org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at localhost# org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [localhost#]: skipping state transfer. No members active in cluster group. Please find the cluster settings (inside the * *tag) below. I have also added the * *tag to the *web.xml *files. *Node_1* Why channelStartOptions=3 ? I think this shoudl use the default. Minor point but I try not to define values that are using the defaults so I cam more easily see the 'interesting' settings. What am I doing wrong here? Any help would be greatly appreciated. Nothing else jumps out at me immediately. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 build from scratch
On 30/11/2023 23:38, Aditya Shastri wrote: Thanks for the response Adwait. My ant skills are lacking. Does the minimum bytecode definition come from this line? Yes. Equally importantly it also ensures that the code is compiled against the Java 8 API. What does this line do? It is used for property replacement in the documentation for the minimum Java version required at runtime. We do it this way so the documentation source files can be the same for all Tomcat versions with the correct minimum version being inserted via this property. It makes it a lot easier when we start a new major version as we only have to change the minimum version in one place rather than searching through the documentation to find all the places that reference the minimum version. Mark On Thu, Nov 30, 2023 at 6:10 PM Adwait Kumar Singh wrote: Yes, JDK17 can produce JDK8 bytecode, in fact that's what Tomcat does. On Thu, Nov 30, 2023 at 2:35 PM Aditya Shastri wrote: Hello, We build our own Tomcat 9 binaries from scratch (grab the tag from https://github.com/apache/tomcat) and call ant (with java8) to build it. Starting with 9.0.83, our pipelines are failing with the error build.xml:113: Java version 17 or newer is required (1.8.0_381 is installed) The apps we have are only certified on Java 8 and it would take a bit of work to get it to Java 17. My question is if I build the binaries with Java 17, can I still use it with Java 8? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
(No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast
Hi, I am trying to implement non-sticky session replication using Delta Manager with static membership. The nodes are across two different machines. I am unable to discover members in the cluster with the following logs on both machines - org.apache.catalina.ha.session.DeltaManager.startInternal Register manager localhost# to cluster element Engine with name Catalina org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at localhost# org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [localhost#]: skipping state transfer. No members active in cluster group. Please find the cluster settings (inside the * *tag) below. I have also added the * *tag to the *web.xml *files. *Node_1* *Node_2* What am I doing wrong here? Any help would be greatly appreciated. Sincerely Manak Bisht
