Re: Virtual event focussed on Tomcat Security
Raghu, On 9/30/20 10:35, Mysore, Raghunath wrote: > This plan about Tomcat security is very nice. We look forward to the > meetings. > > Could we have a session related to " Best practices for using Tomcat > + (Apache Web Server) Forward Proxy (FP) combo in a real production > environment " where an application hosted in Tomcat (web) container, > targets a destination system in the internet, through the FP ? There are some presentations already on our "presentations" page that might address some of your questions. Is there something specific that is missing? http://tomcat.apache.org/presentations.html > The application communicates with the destination system on a TLS > channel. The FP is placed in a perimeter zone. The role of FP is to > route the intranet traffic to the destination system in internet. This sounds like a fairly specific use-case. Are you looking for help in building such a system, or some suggestions for making sure that it's secure, high-performance, etc.? > Is there any generalized document that makes assessment (and > recommendations) of a Tomcat plus a Forward Proxy combo, in a real > word set up ? No, but it would probably be an interesting subject for a presentation. Maybe you could work with others in the community to develop such a presentation and in fact present it at an upcoming conference! -chris > -Original Message- > From: Maarten van Hulsentop > Sent: Wednesday, September 30, 2020 3:10 AM > To: Tomcat Users List > Subject: Re: Virtual event focussed on Tomcat Security > > Hi Mark, > > This sounds like a great idea to me. Security is a very important topic, and > the maturity of the Tomcat makes it a very secure choice for users. I am sure > a lot of people will be interested to join in. > > What is not completely clear to me on this event; would this event be > focussed on improving the security of Tomcat from within (as a Hackathon > suggests)? Like trying to find security flaws/improvements and get them fixed. > or is this meant to be an educational event where information is shared about > secure setups/hardening of the Tomcat in production systems? Or a little of > both? > > For the educational/hardening aspect, it could be nice to team up > with/involve OWASP? > > I am surely interested to pitch in on this topic! > > Kind regards, > > Maarten van Hulsentop > > Op di 29 sep. 2020 om 13:26 schreef Mark Thomas : > >> Hi all, >> >> We (the Tomcat community) have some funding from Google to help us >> improve Tomcat security. Our original plan was to use the funding to >> support an in-person security focussed hackathon. As you would expect, >> those plans are on hold for now. We would, therefore, like to explore >> the possibility of doing something virtually. >> >> The purpose of this email is to gather input from the community about >> what such an event should look like. With that input we can put >> together a plan for the event. So, over to you. What would your ideal >> virtual event focussed on Tomcat Security look like? >> >> Thanks, >> >> Mark >> >> - >> 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: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)
Thank you so much Mark .
We will test and keep you posted .
Thanks and Regards
Arshiya Shariff
-Original Message-
From: Mark Thomas
Sent: Thursday, October 1, 2020 2:59 PM
To: users@tomcat.apache.org
Subject: Re: HTTP2: memory filled up fast on increasing the connections to
1000/2000 (Embedded tomcat 9.0.38)
On 30/09/2020 18:47, Martin Grigorov wrote:
> On Wed, Sep 30, 2020 at 7:47 PM Mark Thomas wrote:
>> On 30/09/2020 16:17, Mark Thomas wrote:
>>> That is helpful. Looks like you have found a way to reproduce the
>>> buffer issues reported in
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64710
>>
>> Can you share the command you used to trigger those errors please.
>>
>
> The Vegeta command I used is:
>
> jq -ncM '{"method": "POST", "url":
> "https://localhost:8080/testbed/plaintext;,
> "body":"payload=Some
> sdgggwwsdgssfshffheeepayload"
> | @base64, header: {"Content-Type":
> ["application/x-www-form-urlencoded"]}}' | vegeta attack -format=json
> -http2 -rate=1000 -max-workers=8 -insecure -duration=2m | vegeta
> encode > /tmp/http2.json; and vegeta report -type=json /tmp/http2.json | jq .
>
> The app is at
> https://protect2.fireeye.com/v1/url?k=c248c6cb-9ce86806-c2488650-866132fe445e-bcef5199a0b9f57e=1=5f78363c-a75a-4bc1-b339-a919d2804f90=https%3A%2F%2Fgithub.com%2Fmartin-g%2Fhttp2-server-perf-tests%2Ftree%2Fmaster%2Fjava%2Ftomcat.
> Just start EmbeddedTomcat#main() with -Dtomcat.http2=true
Definitely timing related as I am unable to reproduce the problem with that
command or some variations.
However, I think I have managed to track down the root cause. The good news is
that the BufferOverflowException is largely harmless. It is a side-effect of
the connection being closed due to an error. My guess is that the error was a
combination of vegeta sending an unexpected reset frame and Tomcat maintaining
state for a very small number of streams in some circumstances.
If you could retest with the latest 9.0.x that would be very helpful.
The memory usage, stream state maintenance and this BufferOverflowException
should all be fixed.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)
On Thu, Oct 1, 2020 at 12:29 PM Mark Thomas wrote:
> On 30/09/2020 18:47, Martin Grigorov wrote:
> > On Wed, Sep 30, 2020 at 7:47 PM Mark Thomas wrote:
> >> On 30/09/2020 16:17, Mark Thomas wrote:
>
>
>
> >>> That is helpful. Looks like you have found a way to reproduce the
> buffer
> >>> issues reported in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64710
> >>
> >> Can you share the command you used to trigger those errors please.
> >>
> >
> > The Vegeta command I used is:
> >
> > jq -ncM '{"method": "POST", "url": "
> https://localhost:8080/testbed/plaintext;,
> > "body":"payload=Some
> >
> sdgggwwsdgssfshffheeepayload"
> > | @base64, header: {"Content-Type":
> > ["application/x-www-form-urlencoded"]}}' | vegeta attack -format=json
> > -http2 -rate=1000 -max-workers=8 -insecure -duration=2m | vegeta encode >
> > /tmp/http2.json; and vegeta report -type=json /tmp/http2.json | jq .
> >
> > The app is at
> >
> https://github.com/martin-g/http2-server-perf-tests/tree/master/java/tomcat
> .
> > Just start EmbeddedTomcat#main() with -Dtomcat.http2=true
>
> Definitely timing related as I am unable to reproduce the problem with
> that command or some variations.
>
> However, I think I have managed to track down the root cause. The good
> news is that the BufferOverflowException is largely harmless. It is a
> side-effect of the connection being closed due to an error. My guess is
> that the error was a combination of vegeta sending an unexpected reset
> frame and Tomcat maintaining state for a very small number of streams in
> some circumstances.
>
> If you could retest with the latest 9.0.x that would be very helpful.
> The memory usage, stream state maintenance and this
> BufferOverflowException should all be fixed.
>
Yesterday it was very easy to reproduce it here.
It looks good now - both exception types didn't happen in several runs!
But something new broke:
SEVERE: Servlet.service() for servlet [plaintext] in context with path []
threw exception
java.lang.NullPointerException: Cannot throw exception because "ioe" is null
at
org.apache.coyote.http2.Http2UpgradeHandler.handleAppInitiatedIOException(Http2UpgradeHandler.java:797)
at
org.apache.coyote.http2.Http2AsyncUpgradeHandler.handleAsyncException(Http2AsyncUpgradeHandler.java:276)
at
org.apache.coyote.http2.Http2AsyncUpgradeHandler.writeWindowUpdate(Http2AsyncUpgradeHandler.java:252)
at org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1088)
at org.apache.coyote.Request.doRead(Request.java:555)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336)
at
org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132)
at org.apache.catalina.connector.Request.readPostBody(Request.java:3308)
at org.apache.catalina.connector.Request.parseParameters(Request.java:3241)
at org.apache.catalina.connector.Request.getParameter(Request.java:1124)
at
org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:381)
at info.mgsolutions.tomcat.PlainTextServlet.doPost(PlainTextServlet.java:41)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:652)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
I will improve it!
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)
On 30/09/2020 18:47, Martin Grigorov wrote:
> On Wed, Sep 30, 2020 at 7:47 PM Mark Thomas wrote:
>> On 30/09/2020 16:17, Mark Thomas wrote:
>>> That is helpful. Looks like you have found a way to reproduce the buffer
>>> issues reported in https://bz.apache.org/bugzilla/show_bug.cgi?id=64710
>>
>> Can you share the command you used to trigger those errors please.
>>
>
> The Vegeta command I used is:
>
> jq -ncM '{"method": "POST", "url": "https://localhost:8080/testbed/plaintext;,
> "body":"payload=Some
> sdgggwwsdgssfshffheeepayload"
> | @base64, header: {"Content-Type":
> ["application/x-www-form-urlencoded"]}}' | vegeta attack -format=json
> -http2 -rate=1000 -max-workers=8 -insecure -duration=2m | vegeta encode >
> /tmp/http2.json; and vegeta report -type=json /tmp/http2.json | jq .
>
> The app is at
> https://github.com/martin-g/http2-server-perf-tests/tree/master/java/tomcat.
> Just start EmbeddedTomcat#main() with -Dtomcat.http2=true
Definitely timing related as I am unable to reproduce the problem with
that command or some variations.
However, I think I have managed to track down the root cause. The good
news is that the BufferOverflowException is largely harmless. It is a
side-effect of the connection being closed due to an error. My guess is
that the error was a combination of vegeta sending an unexpected reset
frame and Tomcat maintaining state for a very small number of streams in
some circumstances.
If you could retest with the latest 9.0.x that would be very helpful.
The memory usage, stream state maintenance and this
BufferOverflowException should all be fixed.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
