Re: AWS health check problems
On 01/03/2021 22:35, Jake Orel wrote: Hi All, I'm working on deploying tomcat through aws with the use of an elastic load balancer connected to an auto scaling group. I'm running into an issue where the health checks associated with the target group are being sent to my server via IP address and therefore the host isn't seeing it so it can't connect to my appbase resulting in 404 health checks. Since I will be utilizing auto scaling I won't always know what ip address will be used to make the request with and if a health check fails auto scaling will terminate my instance. What I'm looking to do is: if a request comes in from a non listed host (A.E an ip address) I want tomcat to use a default host to respond with. If anyone has any ideas as to where I could find some documentation or if they have already faced this problem any information would be very helpful. The default Tomcat configuration has a single default host that handles all requests to every host. If you have multiple hosts, the defaultHost is defined on the Engine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reg: caching allowed setting in tomcat
On 01/03/2021 16:03, Jalaj Asher wrote: I see that the cachingallowed setting is primarily for static content caching. But considering my application we have a lot of static content data resulting in almost 100 to 150 MB of heap memory being used because of this caching. 1. Is there any way to do this caching on disk ? What would be the point of that? That static content is already on disk. It is being cached in memory to improve performance. 1. My static content is being cached in the browser on client end . any negative repercussions that I should be aware off if I disable caching on the tomcat end ? for eg will it impact jsp compilations on the tomcat ? I assume not as they are not static but wanted to confirm. JSP source is static content. Disabling caching may impact JSP compilation time but OS level caching may mitigate that. There many variables that impact performance. The only way to get true sense of the impact is to measure performance with caching enabled and disabled and compare the two. Generally, deploying your application as a WAR file with unpackWARs="false" has the biggest negative impact on performance. If you deploy with unpackWARs="true" or as a directory then I suspect the difference will be minimal. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AWS health check problems
Hi All, I'm working on deploying tomcat through aws with the use of an elastic load balancer connected to an auto scaling group. I'm running into an issue where the health checks associated with the target group are being sent to my server via IP address and therefore the host isn't seeing it so it can't connect to my appbase resulting in 404 health checks. Since I will be utilizing auto scaling I won't always know what ip address will be used to make the request with and if a health check fails auto scaling will terminate my instance. What I'm looking to do is: if a request comes in from a non listed host (A.E an ip address) I want tomcat to use a default host to respond with. If anyone has any ideas as to where I could find some documentation or if they have already faced this problem any information would be very helpful.
Reg: caching allowed setting in tomcat
I see that the cachingallowed setting is primarily for static content caching. But considering my application we have a lot of static content data resulting in almost 100 to 150 MB of heap memory being used because of this caching. 1. Is there any way to do this caching on disk ? 1. My static content is being cached in the browser on client end . any negative repercussions that I should be aware off if I disable caching on the tomcat end ? for eg will it impact jsp compilations on the tomcat ? I assume not as they are not static but wanted to confirm. Thanks Jalaj P Asher CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential information belonging to the sender that is legally privileged and proprietary and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: Tomcat Security Office Hours
On 01/03/2021 11:16, Rony G. Flatscher (Apache) wrote: On 24.02.2021 12:59, Mark Thomas wrote: All, Inspired by this post [1] I am going to try an experiment with running weekly office hours every Thursday. I'm going to start off by focussing on security. If there is anything you'd like to discuss and/or provide feedback on and/or ask questions about around Tomcat security then feel free to book a 20 min slot via: https://calendly.com/markt-asf Slots are available every Thursday. Booking a meeting should trigger a Zoom invite for the requested slot. This is an experiment so the number of slots, timing of slots etc are subject to change as the experiment progresses. If Tomcat security turns out to be too narrow a focus, I'll open it up to anything Tomcat related. Mark [1] https://simonwillison.net/2021/Feb/19/office-hours/ Just curious: how did it work out? No-one booked a slot. Not sure if this was due to short notice, lack of interest or something else. I'll keep the topic focussed on security for another week and if I still don't get any interest I'll open it up to anything Tomcat related. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Security Office Hours
On 24.02.2021 12:59, Mark Thomas wrote: > All, > > Inspired by this post [1] I am going to try an experiment with running > weekly office hours every Thursday. > > I'm going to start off by focussing on security. If there is anything > you'd like to discuss and/or provide feedback on and/or ask questions > about around Tomcat security then feel free to book a 20 min slot via: > > https://calendly.com/markt-asf > > Slots are available every Thursday. Booking a meeting should trigger a > Zoom invite for the requested slot. > > This is an experiment so the number of slots, timing of slots etc are > subject to change as the experiment progresses. If Tomcat security turns > out to be too narrow a focus, I'll open it up to anything Tomcat related. > > Mark > > > [1] https://simonwillison.net/2021/Feb/19/office-hours/ Just curious: how did it work out? ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2021-25329 Apache Tomcat Incomplete fix for CVE-2020-9484 (RCE via session persistence)
CVE-2021-25329 Incomplete fix for CVE-2020-9484 (RCE via session persistence) Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.0 Apache Tomcat 9.0.0.M1 to 9.0.41 Apache Tomcat 8.5.0 to 8.5.61 Apache Tomcat 7.0.0 to 7.0.107 Description: The fix for CVE-2020-9484 was incomplete. When using a highly unlikely configuration edge case, the Tomcat instance was still vulnerable to CVE-2020-9484. Note that both the previously published prerequisites for CVE-2020-9484 also apply to this issue. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.2 or later - Upgrade to Apache Tomcat 9.0.43 or later - Upgrade to Apache Tomcat 8.5.63 or later - Upgrade to Apache Tomcat 7.0.108 or later - the the previously published non-upgrade mitigations for CVE-2020-9484 also apply to this issue Note that issue was fixed in 10.0.1, 9.0.42 and 8.5.62 but the release votes for those versions did not pass. Credit: This issue was identified by Trung Pham of Viettel Cyber Security. History: 2021-03-01 Original advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html [4] https://tomcat.apache.org/security-7.html OpenPGP_signature Description: OpenPGP digital signature
[SECURITY] CVE-2021-25122 Apache Tomcat h2c request mix-up
CVE-2021-25122 h2c request mix-up Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.0 Apache Tomcat 9.0.0.M1 to 9.0.41 Apache Tomcat 8.5.0 to 8.5.61 Description: When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.2 or later - Upgrade to Apache Tomcat 9.0.43 or later - Upgrade to Apache Tomcat 8.5.63 or later Note that issue was fixed in 10.0.1, 9.0.42 and 8.5.62 but the release votes for those versions did not pass. Credit: This issue was identified by the Apache Tomcat Security Team. History: 2021-03-01 Original advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html [4] https://tomcat.apache.org/security-7.html OpenPGP_signature Description: OpenPGP digital signature
