RE: Error parsing HTTP request header
May I know the tomcat version please. - It is apache-tomcat-8.0.41 -Original Message- From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in] Sent: 26 February 2020 19:01 To: 'Tomcat Users List' Subject: Error parsing HTTP request header Dear Team, We are getting below error in catelina log while starting the tomcat. 26-Feb-2020 18:57:36.795 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 21520 ms 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNio InputBuffer.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Proce ssor.java:1017) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac tProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.jav a:1524) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java: 1480) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 49) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 24) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja va:61) at java.lang.Thread.run(Thread.java:748) Will this impact any performance of our tomcat. Thanks & Regards Deepak Kumar CCIL - IT 022-61546230 CIN of CCIL- U65990MH2001PLC131804 "Disclaimer and confidentiality clause - This message and any attachments relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original addressee only. The message may contain information that is confidential and subject to legal privilege. Any views expressed in this message are those of the individual sender. If you have received this message in error, please notify the original sender immediately and destroy the message and copies thereof and any attachments contained in it . If you are not the intended recipient of this message, you are hereby notified that you must not disseminate, copy, use, distribute, or take any action in connection therewith. CCIL cannot ensure that the integrity of this communication has been maintained nor that it is free of errors, viruses, interception and/or interference. CCIL is not liable whatsoever for loss or damage resulting from the opening of this message and/or attachments and/or the use of the information contained in this message and/or attachments."
Re: Tomcat 9.31 PUT/POST Request receiving Partial Data
The response get truncated after 16321 bytes. Please let me know what is
best way to wait and in order to consume entire request payload.
Thanks,
Bhavesh
On Wed, Feb 26, 2020 at 4:34 PM Bhavesh Mistry
wrote:
> Hi Tomcat Team,
>
> I have servlet filter for all requests to cache the entire PUT/POST
> Payload. When content is large 4KB or more, I am getting partial content
> when I read from HttpServletRequest.getInputStream(). But I but 10 seconds
> wait before consuming the input stream, I am getting entire content. Can
> you please let me know what is the correct way to wait for the entire
> content is ready to consume from the tomcat servlet request input stream?
>
>
> Filter Code:
> If I put Thread.sleep(10) at begin of filter, I am getting full
> content.
>
> @Override
> protected void doFilterInternal(HttpServletRequest httpServletRequest,
> HttpServletResponse httpServletResponse, FilterChain filterChain) throws
> ServletException, IOException {
> CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new
> CachedBodyHttpServletRequest(httpServletRequest);
> filterChain.doFilter(cachedBodyHttpServletRequest, httpServletResponse);
> }
>
> // Wrapper to cache content.
>
> public CachedBodyHttpServletRequest(HttpServletRequest request) throws
> IOException {
> super(request);
> ServletInputStream inputStream = request.getInputStream();
> final int len = request.getContentLength();
> if (len >= 0) {
> cachedBody = new byte[len];
> ByteStreams.readFully(inputStream, cachedBody);
> } else {
> cachedBody = ByteStreams.toByteArray(inputStream);
> }
> }
>
>
> Thanks,
>
> Bhavesh
>
Tomcat 9.31 PUT/POST Request receiving Partial Data
Hi Tomcat Team,
I have servlet filter for all requests to cache the entire PUT/POST
Payload. When content is large 4KB or more, I am getting partial content
when I read from HttpServletRequest.getInputStream(). But I but 10 seconds
wait before consuming the input stream, I am getting entire content. Can
you please let me know what is the correct way to wait for the entire
content is ready to consume from the tomcat servlet request input stream?
Filter Code:
If I put Thread.sleep(10) at begin of filter, I am getting full
content.
@Override
protected void doFilterInternal(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse, FilterChain filterChain)
throws ServletException, IOException {
CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new
CachedBodyHttpServletRequest(httpServletRequest);
filterChain.doFilter(cachedBodyHttpServletRequest, httpServletResponse);
}
// Wrapper to cache content.
public CachedBodyHttpServletRequest(HttpServletRequest request) throws
IOException {
super(request);
ServletInputStream inputStream = request.getInputStream();
final int len = request.getContentLength();
if (len >= 0) {
cachedBody = new byte[len];
ByteStreams.readFully(inputStream, cachedBody);
} else {
cachedBody = ByteStreams.toByteArray(inputStream);
}
}
Thanks,
Bhavesh
/manager/text/list fails in 9.0.31, works in 9.0.27
Corrected subject - Hello, I have manager endpoint enabled in my tomcat install. When I list the manager endoing in tomcat 9.0.31, I get a 401 Unauthorized error - curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list http://www.w3.org/TR/html4/strict.dtd";> 401 Unauthorized ... However, when I call it in tomcat 9.0.27 it works as expected... curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat 9.0.27 it works as expected... OK - Listed applications for virtual host [localhost] /manager:running:0:manager The password is configured in tomcat-users.xml using the output from /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdigest.sh&c=E,1,3tDk5vwY_zoM19PIwVKe3fyfwRAXV_7a8MrPXyx5XiQ5db4bmp89IB1v74yX6cNBQO6ob5X1vfgWGe5Fe0T0DHm6eweKRmHiAyvxG_4cIwsd218AJPe3&typo=1 -a sha-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler secret secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82 > cat /opt/tomcat/conf/tomcat-users.xml ... ... I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be identical. Can someone please help me what I may need to configure more? Regards, Vishal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
/manage/text/list fails in 9.0.31, works in 9.0.27
Hello, I have manager endpoint enabled in my tomcat install. When I list the manager endoing in tomcat 9.0.31, I get a 401 Unauthorized error - curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list http://www.w3.org/TR/html4/strict.dtd";> 401 Unauthorized ... However, when I call it in tomcat 9.0.27 it works as expected... curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat 9.0.27 it works as expected... OK - Listed applications for virtual host [localhost] /manager:running:0:manager The password is configured in tomcat-users.xml using the output from /opt/tomcat/bin/digest.sh -a sha-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler secret secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82 > cat /opt/tomcat/conf/tomcat-users.xml ... ... I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be identical. Can someone please help me what I may need to configure more? Regards, Vishal
Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat
So I really can't believe it, but it WORKS, from end to end. I'm extremely grateful. This was definitely becoming a bit stressful until I found this mailing list. I'll have to do some more complete testing but this is looking good. Regarding the next release of Tomcat, I may as well give it a try. Tomcat 9, which I tried first, until I ran into this mystery problem, so backed off to v.8.5.51, has tightened down by forbidding certain characters in the request, which gave me a few bad moments until I figured out how to allow them again. Hopefully not too many new surprises in TC 10. Ellen On Wed, Feb 26, 2020 at 12:29 PM Mark Thomas wrote: > On 26/02/2020 17:15, Ellen Meiselman wrote: > > One more piece of the puzzle: > > Setting allowedRequestAttributesPattern=".*" WORKED. > > So if I get the exact pattern right, that may be the answer. > > You'll all have to forgive me - I really don't know much about this > stuff - > > I'm mostly a front-end developer who is sort of the "last woman standing" > > to support this particular application. So I don't know a lot of the > > basics. > > The specific match setting should be: > > > allowedRequestAttributesPattern="CERT_(ISSUER|SUBJECT|COOKIE|FLAGS|SERIALNUMBER)|HTTPS_(SERVER_(SUBJECT|ISSUER)|(SECRETKEYSIZE|KEYSIZE))" > > All on one line. > > Tested with IIS on Server 2019 and Tomcat 9.0.31. > > You should be able to make it a little more efficient if you re-work the > final two literals. > > Once you upgrade to the next Tomcat release (should be available ewarly > next month), you can remove the allowedRequestAttributesPattern setting. > Those Tomcat versions will do this automatically. > > Mark > > > > > > Thank you, > > Ellen > > > > > > On Wed, Feb 26, 2020 at 9:25 AM > > wrote: > > > >> -Original Message- > >>> From: Mark Thomas > >>> Sent: Wednesday, February 26, 2020 5:19 AM > >>> To: users@tomcat.apache.org > >>> Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > >> andTomcat > >> > >>> On 26/02/2020 09:00, Mark Thomas wrote: > >>> On 25/02/2020 21:47, Ellen Meiselman wrote: > So it turned out that the logs were mostly set at FINE already, so > >>> Johann’s suggestion was already done. > > But I think I now know where the problem lies. Secure IIS request > > >>> to > non-secire AJP. > > I don’t think this was a problem on the other servers before but the > >>> security has probably been tightened, and it just doesn’t produce an > >>> error - it just won’t allow it. > > I have had IIS set to require SSL, but I turned it off to test and it > >>> actually worked all the way through to the simple.html file. so it’s > >>> some sort of policy about downgrading - which seems quite rational in > >>> retrospect > >>> > >>> Thanks for the new information. > >>> > >>> That rules out an issue with the secret settings. > >>> > >>> I wonder if IIS (or more likely the ISAPI redirector) is adding some > >>> unexpected request attributes that is triggering the new protection > >>> for CVE-2020-1938. If that is the case, adding the following to your > >>> AJP connector in server.xml should get things working for SSL as well: > >>> > >>> allowedRequestAttributesPattern=".*" > >>> > >>> Meanwhile, I'll configure my local test environment for IIS with TLS > >>> and see what happens. > >> > >>> Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > >>> works around it. > >> > >>> I need to debug further to find out exactly what the attributes are. I > >> expect we'll add them to the ones Tomcat accepts by default. > >> > >>> Mark > >> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> Thanks Mark, > >> So, to be clear, add > >> > >> allowedRequestAttributesPattern=".*" > >> > >> to the AJP Connector in server.xml IF you are using IIS as the > Front-End, > >> using the AJP Plugin and having SSL configured in IIS? > >> > >> Thanks, > >> > >> Dream * Excel * Explore * Inspire > >> Jon McAlexander > >> Asst Vice President > >> > >> Middleware Product Engineering > >> Enterprise CIO | Platform Services | Middleware | Infrastructure > Solutions > >> > >> Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, > 12/13, > >> 12/20 – 12/31 > >> > >> 8080 Cobblestone Rd | Urbandale, IA 50322 > >> MAC: F4469-010 > >> Tel 515-988-2508 | Cell 515-988-2508 > >> > >> jonmcalexan...@wellsfargo.com > >> > >> > >> This message may contain confidential and/or privileged information. If > >> you are not the addressee or authorized to receive this for the > addressee, > >> you must not use, copy, disclose, or take any action based on this > message > >> or any information herein. If you have received this message in error, > >> please advise the sender immediately by reply e-mail and delete this > >> message. Thank you for your cooperatio
RE: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
Thank you sir! Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Christopher Schultz Sent: Wednesday, February 26, 2020 11:18 AM To: users@tomcat.apache.org Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon, On 2/26/20 09:25, jonmcalexan...@wellsfargo.com.INVALID wrote: > -Original Message- >> From: Mark Thomas Sent: Wednesday, February 26, >> 2020 5:19 AM To: users@tomcat.apache.org Subject: Re: [OT] At wits >> end: Difficulties with IIS ISAPI connector andTomcat > >> On 26/02/2020 09:00, Mark Thomas wrote: On 25/02/2020 21:47, Ellen >> Meiselman wrote: >>> So it turned out that the logs were mostly set at FINE already, so >> Johann’s suggestion was already done. >>> >>> But I think I now know where the problem lies. Secure IIS >>> request > >> to > non-secire AJP. >>> >>> I don’t think this was a problem on the other servers before >>> but the >> security has probably been tightened, and it just doesn’t produce >> an error - it just won’t allow it. >>> >>> I have had IIS set to require SSL, but I turned it off to test >>> and it >> actually worked all the way through to the simple.html file. so >> it’s some sort of policy about downgrading - which seems quite >> rational in retrospect >> >> Thanks for the new information. >> >> That rules out an issue with the secret settings. >> >> I wonder if IIS (or more likely the ISAPI redirector) is adding >> some unexpected request attributes that is triggering the new >> protection for CVE-2020-1938. If that is the case, adding the >> following to your AJP connector in server.xml should get things >> working for SSL as well: >> >> allowedRequestAttributesPattern=".*" >> >> Meanwhile, I'll configure my local test environment for IIS with >> TLS and see what happens. > >> Confirmed. That is the issue and >> allowedRequestAttributesPattern=".*" works around it. > >> I need to debug further to find out exactly what the attributes >> are. I expect we'll add them to the ones Tomcat accepts by >> default. > >> Mark > >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks Mark, So, to be clear, add > > allowedRequestAttributesPattern=".*" > > to the AJP Connector in server.xml IF you are using IIS as the > Front-End, using the AJP Plugin and having SSL configured in IIS? And also if you can convince yourself that nobody is going to make malicious connections to your AJP port. It looks like Mark found the set of attributes that need to be added to the whitelist; if you look at those patches, you can put just those items into the pattern (e.g. allowedRequestAttributesPattern="(CLIENT_CERT|..." to be as safe as possible. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5WqDoACgkQHPApP6U8 pFhR7w/+IjEhNdUThQtdjfI8AVA/ZhsFTsbnmQq+Ue++fCUmxPbnPPC1alJK1RNx RkaDZTgjUXPZD2H7DgKd0zXpdNEGrDetCY+mOE2UTIyGPM8T9a14nFB7/gOw7hPX +WlnoI5EtV9YaKreM/qniM4kJLY5y//OenzEDKL1MQGqHBm9A7JxkM/L0+5aBn47 tzIKcjX+ZBsDitmyn6rmSGjPnm+7yRsRM84T8uw97LI1mSTNCUhGjTF44kkSbgsf 9nLRRyVXa9/HlJMcbtZm1NOd4UZbsikcP6VHg7RvNxZNrAcWDorCyhlS1xdBMJZe LE+FQKpoE8KLJa9G1bU0ANea7wSo/TSA18HE4Rn7t40XCWsIut3B8cyhXQKoBaoN seoyue1XmqB82YrQAEe31qyINYB9PK/7XV0cznWR80I9CoJa5QQXHKAeDt3Ct/Bx IWHNi5KCOD4c8UwCxnVA05vJIHGsUhsuwDtXDUbcZWD1YkHtL2k6GHXXrWt9xnho jD8WW+wsj1ut85PjyujMAvoYW0aUUAcSsGZF2nqnoIr+2UD+DHAgqfSzrXaNO/BH cjiUbJREjyV7hgsiyWxZBfnxC1825GWfpVEgw1sC7qpC3ik3QdNZJbYbJk1EcK40 blvQ/xxnQ1nb2tdq6Ozn0xX3KlOqhZpl0l+FKs5Wz3QPXbHEqKM= =2eup -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat
On 26/02/2020 17:15, Ellen Meiselman wrote: > One more piece of the puzzle: > Setting allowedRequestAttributesPattern=".*" WORKED. > So if I get the exact pattern right, that may be the answer. > You'll all have to forgive me - I really don't know much about this stuff - > I'm mostly a front-end developer who is sort of the "last woman standing" > to support this particular application. So I don't know a lot of the > basics. The specific match setting should be: allowedRequestAttributesPattern="CERT_(ISSUER|SUBJECT|COOKIE|FLAGS|SERIALNUMBER)|HTTPS_(SERVER_(SUBJECT|ISSUER)|(SECRETKEYSIZE|KEYSIZE))" All on one line. Tested with IIS on Server 2019 and Tomcat 9.0.31. You should be able to make it a little more efficient if you re-work the final two literals. Once you upgrade to the next Tomcat release (should be available ewarly next month), you can remove the allowedRequestAttributesPattern setting. Those Tomcat versions will do this automatically. Mark > > Thank you, > Ellen > > > On Wed, Feb 26, 2020 at 9:25 AM > wrote: > >> -Original Message- >>> From: Mark Thomas >>> Sent: Wednesday, February 26, 2020 5:19 AM >>> To: users@tomcat.apache.org >>> Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector >> andTomcat >> >>> On 26/02/2020 09:00, Mark Thomas wrote: >>> On 25/02/2020 21:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so >>> Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request > >>> to > non-secire AJP. I don’t think this was a problem on the other servers before but the >>> security has probably been tightened, and it just doesn’t produce an >>> error - it just won’t allow it. I have had IIS set to require SSL, but I turned it off to test and it >>> actually worked all the way through to the simple.html file. so it’s >>> some sort of policy about downgrading - which seems quite rational in >>> retrospect >>> >>> Thanks for the new information. >>> >>> That rules out an issue with the secret settings. >>> >>> I wonder if IIS (or more likely the ISAPI redirector) is adding some >>> unexpected request attributes that is triggering the new protection >>> for CVE-2020-1938. If that is the case, adding the following to your >>> AJP connector in server.xml should get things working for SSL as well: >>> >>> allowedRequestAttributesPattern=".*" >>> >>> Meanwhile, I'll configure my local test environment for IIS with TLS >>> and see what happens. >> >>> Confirmed. That is the issue and allowedRequestAttributesPattern=".*" >>> works around it. >> >>> I need to debug further to find out exactly what the attributes are. I >> expect we'll add them to the ones Tomcat accepts by default. >> >>> Mark >> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> Thanks Mark, >> So, to be clear, add >> >> allowedRequestAttributesPattern=".*" >> >> to the AJP Connector in server.xml IF you are using IIS as the Front-End, >> using the AJP Plugin and having SSL configured in IIS? >> >> Thanks, >> >> Dream * Excel * Explore * Inspire >> Jon McAlexander >> Asst Vice President >> >> Middleware Product Engineering >> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions >> >> Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, >> 12/20 – 12/31 >> >> 8080 Cobblestone Rd | Urbandale, IA 50322 >> MAC: F4469-010 >> Tel 515-988-2508 | Cell 515-988-2508 >> >> jonmcalexan...@wellsfargo.com >> >> >> This message may contain confidential and/or privileged information. If >> you are not the addressee or authorized to receive this for the addressee, >> you must not use, copy, disclose, or take any action based on this message >> or any information herein. If you have received this message in error, >> please advise the sender immediately by reply e-mail and delete this >> message. Thank you for your cooperation. >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon, On 2/26/20 09:25, jonmcalexan...@wellsfargo.com.INVALID wrote: > -Original Message- >> From: Mark Thomas Sent: Wednesday, February >> 26, 2020 5:19 AM To: users@tomcat.apache.org Subject: Re: [OT] At >> wits end: Difficulties with IIS ISAPI connector andTomcat > >> On 26/02/2020 09:00, Mark Thomas wrote: On 25/02/2020 21:47, >> Ellen Meiselman wrote: >>> So it turned out that the logs were mostly set at FINE already, >>> so >> Johann’s suggestion was already done. >>> >>> But I think I now know where the problem lies. Secure IIS >>> request > >> to > non-secire AJP. >>> >>> I don’t think this was a problem on the other servers before >>> but the >> security has probably been tightened, and it just doesn’t produce >> an error - it just won’t allow it. >>> >>> I have had IIS set to require SSL, but I turned it off to test >>> and it >> actually worked all the way through to the simple.html file. so >> it’s some sort of policy about downgrading - which seems quite >> rational in retrospect >> >> Thanks for the new information. >> >> That rules out an issue with the secret settings. >> >> I wonder if IIS (or more likely the ISAPI redirector) is adding >> some unexpected request attributes that is triggering the new >> protection for CVE-2020-1938. If that is the case, adding the >> following to your AJP connector in server.xml should get things >> working for SSL as well: >> >> allowedRequestAttributesPattern=".*" >> >> Meanwhile, I'll configure my local test environment for IIS with >> TLS and see what happens. > >> Confirmed. That is the issue and >> allowedRequestAttributesPattern=".*" works around it. > >> I need to debug further to find out exactly what the attributes >> are. I expect we'll add them to the ones Tomcat accepts by >> default. > >> Mark > >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks Mark, So, to be clear, add > > allowedRequestAttributesPattern=".*" > > to the AJP Connector in server.xml IF you are using IIS as the > Front-End, using the AJP Plugin and having SSL configured in IIS? And also if you can convince yourself that nobody is going to make malicious connections to your AJP port. It looks like Mark found the set of attributes that need to be added to the whitelist; if you look at those patches, you can put just those items into the pattern (e.g. allowedRequestAttributesPattern="(CLIENT_CERT|..." to be as safe as possible. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5WqDoACgkQHPApP6U8 pFhR7w/+IjEhNdUThQtdjfI8AVA/ZhsFTsbnmQq+Ue++fCUmxPbnPPC1alJK1RNx RkaDZTgjUXPZD2H7DgKd0zXpdNEGrDetCY+mOE2UTIyGPM8T9a14nFB7/gOw7hPX +WlnoI5EtV9YaKreM/qniM4kJLY5y//OenzEDKL1MQGqHBm9A7JxkM/L0+5aBn47 tzIKcjX+ZBsDitmyn6rmSGjPnm+7yRsRM84T8uw97LI1mSTNCUhGjTF44kkSbgsf 9nLRRyVXa9/HlJMcbtZm1NOd4UZbsikcP6VHg7RvNxZNrAcWDorCyhlS1xdBMJZe LE+FQKpoE8KLJa9G1bU0ANea7wSo/TSA18HE4Rn7t40XCWsIut3B8cyhXQKoBaoN seoyue1XmqB82YrQAEe31qyINYB9PK/7XV0cznWR80I9CoJa5QQXHKAeDt3Ct/Bx IWHNi5KCOD4c8UwCxnVA05vJIHGsUhsuwDtXDUbcZWD1YkHtL2k6GHXXrWt9xnho jD8WW+wsj1ut85PjyujMAvoYW0aUUAcSsGZF2nqnoIr+2UD+DHAgqfSzrXaNO/BH cjiUbJREjyV7hgsiyWxZBfnxC1825GWfpVEgw1sC7qpC3ik3QdNZJbYbJk1EcK40 blvQ/xxnQ1nb2tdq6Ozn0xX3KlOqhZpl0l+FKs5Wz3QPXbHEqKM= =2eup -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
One more piece of the puzzle: Setting allowedRequestAttributesPattern=".*" WORKED. So if I get the exact pattern right, that may be the answer. You'll all have to forgive me - I really don't know much about this stuff - I'm mostly a front-end developer who is sort of the "last woman standing" to support this particular application. So I don't know a lot of the basics. Thank you, Ellen On Wed, Feb 26, 2020 at 9:25 AM wrote: > -Original Message- > > From: Mark Thomas > > Sent: Wednesday, February 26, 2020 5:19 AM > > To: users@tomcat.apache.org > > Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > andTomcat > > > On 26/02/2020 09:00, Mark Thomas wrote: > > On 25/02/2020 21:47, Ellen Meiselman wrote: > >> So it turned out that the logs were mostly set at FINE already, so > > Johann’s suggestion was already done. > >> > >> But I think I now know where the problem lies. Secure IIS request > > > to > non-secire AJP. > >> > >> I don’t think this was a problem on the other servers before but the > > security has probably been tightened, and it just doesn’t produce an > > error - it just won’t allow it. > >> > >> I have had IIS set to require SSL, but I turned it off to test and it > > actually worked all the way through to the simple.html file. so it’s > > some sort of policy about downgrading - which seems quite rational in > > retrospect > > > > Thanks for the new information. > > > > That rules out an issue with the secret settings. > > > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > > unexpected request attributes that is triggering the new protection > > for CVE-2020-1938. If that is the case, adding the following to your > > AJP connector in server.xml should get things working for SSL as well: > > > > allowedRequestAttributesPattern=".*" > > > > Meanwhile, I'll configure my local test environment for IIS with TLS > > and see what happens. > > > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > > works around it. > > > I need to debug further to find out exactly what the attributes are. I > expect we'll add them to the ones Tomcat accepts by default. > > > Mark > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks Mark, > So, to be clear, add > > allowedRequestAttributesPattern=".*" > > to the AJP Connector in server.xml IF you are using IIS as the Front-End, > using the AJP Plugin and having SSL configured in IIS? > > Thanks, > > Dream * Excel * Explore * Inspire > Jon McAlexander > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, > 12/20 – 12/31 > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose, or take any action based on this message > or any information herein. If you have received this message in error, > please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. >
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/26/20 09:08, Mark Thomas wrote: > On 26/02/2020 11:19, Mark Thomas wrote: >> On 26/02/2020 09:00, Mark Thomas wrote: >>> On 25/02/2020 21:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so >>> Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request > >>> to > non-secire AJP. I don’t think this was a problem on the other servers before but the >>> security has probably been tightened, and it just doesn’t >>> produce an error - it just won’t allow it. I have had IIS set to require SSL, but I turned it off to test and it >>> actually worked all the way through to the simple.html file. so >>> it’s some sort of policy about downgrading - which seems quite >>> rational in retrospect >>> >>> Thanks for the new information. >>> >>> That rules out an issue with the secret settings. >>> >>> I wonder if IIS (or more likely the ISAPI redirector) is adding >>> some unexpected request attributes that is triggering the new >>> protection for CVE-2020-1938. If that is the case, adding the >>> following to your AJP connector in server.xml should get things >>> working for SSL as well: >>> >>> allowedRequestAttributesPattern=".*" >>> >>> Meanwhile, I'll configure my local test environment for IIS >>> with TLS and see what happens. >> >> Confirmed. That is the issue and >> allowedRequestAttributesPattern=".*" works around it. >> >> I need to debug further to find out exactly what the attributes >> are. I expect we'll add them to the ones Tomcat accepts by >> default. > > Added. > > Fixed in: - master for 10.0.0-M2 onwards - 9.0.x for 9.0.32 > onwards - 8.5.x for 8.5.52 onwards - 7.0.x for 7.0.101 onwards > > For reference, the IIS specific attributes will be listed in the > docs. CI version available from: > https://ci.apache.org/projects/tomcat/tomcat9/docs/config/ajp.html#Sta ndard_Implementations Well, > @#$*%&. Sorry, IIS folks. I hope we didn't ruin too many nights and weekends for you. :( - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5WpxcACgkQHPApP6U8 pFiCQBAAqM4R2meJGpAIgO4wAyqW4999+ZCF7AXtyXH0wDa7//RAhNzaNnNvNLNB 5XPQdwhxB5/Ckq7MYL1WBIKnwUZ052EBMnZTIgyOI8SP4NbUdPsovKAD8UAdoFOQ 48drsY27D2ltj9Xqja2hsvAEDLt1A2K3NF3CwhAMZCDz37SyHSpuOOEmSFJ0S1Q8 OtKMtSUsxGVPYmQR1CZwg18Q8XM6S8Rg5GRRpJHEowJ74+3C6CcYBk+i3xFMYMfN WkHEjYZQetyVnvgJqNI0NDsErWehfQ38sZGPsFewtYWXemwAAfnDeVUkr5XXYHSz UmMMlclZnG2CQLpHSklVKKuRJeRDO7CFijNQVkwZwpBtQa1tZFvpUQnsWD6SrXq2 YzGUTQBWHpEL9ZjSuws+uI3H4QmpFp1WhSuOMZoPHpE6m804Q1onWqFe+RPPW8E0 g5ykhzFPE7uo3gBpMUIkuiGVlnMFIQas98K7WApcHXOKryAwSjIBXclNcE5OSVuf synopXnR6w61Fymoq+sr5sTJ64gbVQlsfFDsWvRJhak14Zzt6ZJu3a2T14Yt9Fz3 5NHJZDX9j5gQbfE9ATuoj4L40n7LkE0SrLYaagzkT3B5UaV0IMRdQIyki7bJdV26 zfgAyER3hnC8qEN3THeBPtRVqPpXvXel+AyqRsKgq9RWhMqoPyw= =5nQA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
Hi, For all those of you helping me with the AJP connector allowedRequestAttributesPattern, I've spent some time carefully sanitizing 2 sets of isapi_redirect,log entries and put them up at the link below. These logs were generated from exactly two requests (sanitized version shown) https://myserver.com/MyExposedApplication/simple.html and http://myserver.com/MyExposedApplication/simple.html In other words SSL, and non-SSL. I believe these show the request and headers, and hopefully will help with a discussion of allowed request attributes. Here's the link: https://docs.google.com/document/d/1Y4NNrshG_4_sV4hArP2G0xoAzdxjMvivL_0IVJKE5SM/edit?usp=sharing They'll be up for about 1 day, so please copy the text if you find them useful Ellen On Wed, Feb 26, 2020 at 9:25 AM wrote: > -Original Message- > > From: Mark Thomas > > Sent: Wednesday, February 26, 2020 5:19 AM > > To: users@tomcat.apache.org > > Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > andTomcat > > > On 26/02/2020 09:00, Mark Thomas wrote: > > On 25/02/2020 21:47, Ellen Meiselman wrote: > >> So it turned out that the logs were mostly set at FINE already, so > > Johann’s suggestion was already done. > >> > >> But I think I now know where the problem lies. Secure IIS request > > > to > non-secire AJP. > >> > >> I don’t think this was a problem on the other servers before but the > > security has probably been tightened, and it just doesn’t produce an > > error - it just won’t allow it. > >> > >> I have had IIS set to require SSL, but I turned it off to test and it > > actually worked all the way through to the simple.html file. so it’s > > some sort of policy about downgrading - which seems quite rational in > > retrospect > > > > Thanks for the new information. > > > > That rules out an issue with the secret settings. > > > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > > unexpected request attributes that is triggering the new protection > > for CVE-2020-1938. If that is the case, adding the following to your > > AJP connector in server.xml should get things working for SSL as well: > > > > allowedRequestAttributesPattern=".*" > > > > Meanwhile, I'll configure my local test environment for IIS with TLS > > and see what happens. > > > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > > works around it. > > > I need to debug further to find out exactly what the attributes are. I > expect we'll add them to the ones Tomcat accepts by default. > > > Mark > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks Mark, > So, to be clear, add > > allowedRequestAttributesPattern=".*" > > to the AJP Connector in server.xml IF you are using IIS as the Front-End, > using the AJP Plugin and having SSL configured in IIS? > > Thanks, > > Dream * Excel * Explore * Inspire > Jon McAlexander > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, > 12/20 – 12/31 > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose, or take any action based on this message > or any information herein. If you have received this message in error, > please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. >
RE: Error parsing HTTP request header
May I know the tomcat version please. -Original Message- From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in] Sent: 26 February 2020 19:01 To: 'Tomcat Users List' Subject: Error parsing HTTP request header Dear Team, We are getting below error in catelina log while starting the tomcat. 26-Feb-2020 18:57:36.795 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 21520 ms 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNio InputBuffer.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Proce ssor.java:1017) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac tProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.jav a:1524) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java: 1480) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 49) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 24) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja va:61) at java.lang.Thread.run(Thread.java:748) Will this impact any performance of our tomcat. Thanks & Regards Deepak Kumar CCIL - IT 022-61546230 CIN of CCIL- U65990MH2001PLC131804 "Disclaimer and confidentiality clause - This message and any attachments relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original addressee only. The message may contain information that is confidential and subject to legal privilege. Any views expressed in this message are those of the individual sender. If you have received this message in error, please notify the original sender immediately and destroy the message and copies thereof and any attachments contained in it . If you are not the intended recipient of this message, you are hereby notified that you must not disseminate, copy, use, distribute, or take any action in connection therewith. CCIL cannot ensure that the integrity of this communication has been maintained nor that it is free of errors, viruses, interception and/or interference. CCIL is not liable whatsoever for loss or damage resulting from the opening of this message and/or attachments and/or the use of the information contained in this message and/or attachments." - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
Hi, On Wed, Feb 26, 2020 at 4:25 PM wrote: > -Original Message- > > From: Mark Thomas > > Sent: Wednesday, February 26, 2020 5:19 AM > > To: users@tomcat.apache.org > > Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > andTomcat > > > On 26/02/2020 09:00, Mark Thomas wrote: > > On 25/02/2020 21:47, Ellen Meiselman wrote: > >> So it turned out that the logs were mostly set at FINE already, so > > Johann’s suggestion was already done. > >> > >> But I think I now know where the problem lies. Secure IIS request > > > to > non-secire AJP. > >> > >> I don’t think this was a problem on the other servers before but the > > security has probably been tightened, and it just doesn’t produce an > > error - it just won’t allow it. > >> > >> I have had IIS set to require SSL, but I turned it off to test and it > > actually worked all the way through to the simple.html file. so it’s > > some sort of policy about downgrading - which seems quite rational in > > retrospect > > > > Thanks for the new information. > > > > That rules out an issue with the secret settings. > > > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > > unexpected request attributes that is triggering the new protection > > for CVE-2020-1938. If that is the case, adding the following to your > > AJP connector in server.xml should get things working for SSL as well: > > > > allowedRequestAttributesPattern=".*" > > > > Meanwhile, I'll configure my local test environment for IIS with TLS > > and see what happens. > > > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > > works around it. > > > I need to debug further to find out exactly what the attributes are. I > expect we'll add them to the ones Tomcat accepts by default. > > > Mark > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks Mark, > So, to be clear, add > > allowedRequestAttributesPattern=".*" > > to the AJP Connector in server.xml IF you are using IIS as the Front-End, > using the AJP Plugin and having SSL configured in IIS? > Using ".*" as a value was helpful just for the debugging of the problem. Mark documented the IIS specific attributes in AJP Connector documentation. It would be better to whitelist only them, not everything. Martin > > Thanks, > > Dream * Excel * Explore * Inspire > Jon McAlexander > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, > 12/20 – 12/31 > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose, or take any action based on this message > or any information herein. If you have received this message in error, > please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. >
RE: [OT] At wits end: Difficulties with IIS ISAPI connector and Tomcat
-Original Message- > From: Mark Thomas > Sent: Wednesday, February 26, 2020 5:19 AM > To: users@tomcat.apache.org > Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat > On 26/02/2020 09:00, Mark Thomas wrote: > On 25/02/2020 21:47, Ellen Meiselman wrote: >> So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. >> >> But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. >> >> I don’t think this was a problem on the other servers before but the > security has probably been tightened, and it just doesn’t produce an > error - it just won’t allow it. >> >> I have had IIS set to require SSL, but I turned it off to test and it > actually worked all the way through to the simple.html file. so it’s > some sort of policy about downgrading - which seems quite rational in > retrospect > > Thanks for the new information. > > That rules out an issue with the secret settings. > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > unexpected request attributes that is triggering the new protection > for CVE-2020-1938. If that is the case, adding the following to your > AJP connector in server.xml should get things working for SSL as well: > > allowedRequestAttributesPattern=".*" > > Meanwhile, I'll configure my local test environment for IIS with TLS > and see what happens. > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > works around it. > I need to debug further to find out exactly what the attributes are. I expect > we'll add them to the ones Tomcat accepts by default. > Mark > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Thanks Mark, So, to be clear, add allowedRequestAttributesPattern=".*" to the AJP Connector in server.xml IF you are using IIS as the Front-End, using the AJP Plugin and having SSL configured in IIS? Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: Error parsing HTTP request header
On 26.02.2020 14:30, dku...@ccilindia.co.in wrote: Dear Team, We are getting below error in catelina log while starting the tomcat. 26-Feb-2020 18:57:36.795 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 21520 ms 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Will this impact any performance of our tomcat. It is not quite clear what you mean by that question. Origin of the above : - a HTTP client sent an invalid HTTP request to your tomcat - tomcat caught this, refused the request, and warned you of it by writing a detailed error message to the logfile - tomcat also tells you that if there are any further errors of the same type, you will only see them in the logfile, if you turn the general log level of tomcat to "debug" (which produces *a lot* of messages). That is tomcat's way of saving resources, in case there are many more requests of that kind. Will this impact the performance of tomcat ? Well, of course, if your tomcat continues to receive a lot of such invalid requests all the time, that will use some of the processing time of the tomcat host, even to return an error to the client. But this has nothing to do with your tomcat per se or its configuration, it has to do with bad or malicious clients out there, which send invalid requests to your server, and it would be the same with any webserver. If you want to filter out such requests before they arrive to tomcat, you will have to put in front of tomcat some specialised filtering device which is optimised to do that kind of thing. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error parsing HTTP request header
On 26/02/2020 13:30, dku...@ccilindia.co.in wrote: > Dear Team, > > We are getting below error in catelina log while starting the tomcat. > > 26-Feb-2020 18:57:36.795 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 21520 ms > 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] > org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing > HTTP request header > Note: further occurrences of HTTP header parsing errors will be logged at > DEBUG level. > java.lang.IllegalArgumentException: Invalid character found in the > request target. The valid characters are defined in RFC 7230 and RFC 3986 > at > org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:283) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:748) > > Will this impact any performance of our tomcat. In that Tomcat is wasting cycles processing a request that the client should never have sent, yes, it will impact performance. Does processing an invalid request cost any more than a valid one. On average, no. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 26/02/2020 11:19, Mark Thomas wrote: > On 26/02/2020 09:00, Mark Thomas wrote: >> On 25/02/2020 21:47, Ellen Meiselman wrote: >>> So it turned out that the logs were mostly set at FINE already, so >> Johann’s suggestion was already done. >>> >>> But I think I now know where the problem lies. Secure IIS request > >> to > non-secire AJP. >>> >>> I don’t think this was a problem on the other servers before but the >> security has probably been tightened, and it just doesn’t produce an >> error - it just won’t allow it. >>> >>> I have had IIS set to require SSL, but I turned it off to test and it >> actually worked all the way through to the simple.html file. so it’s >> some sort of policy about downgrading - which seems quite rational in >> retrospect >> >> Thanks for the new information. >> >> That rules out an issue with the secret settings. >> >> I wonder if IIS (or more likely the ISAPI redirector) is adding some >> unexpected request attributes that is triggering the new protection for >> CVE-2020-1938. If that is the case, adding the following to your AJP >> connector in server.xml should get things working for SSL as well: >> >> allowedRequestAttributesPattern=".*" >> >> Meanwhile, I'll configure my local test environment for IIS with TLS and >> see what happens. > > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > works around it. > > I need to debug further to find out exactly what the attributes are. I > expect we'll add them to the ones Tomcat accepts by default. Added. Fixed in: - master for 10.0.0-M2 onwards - 9.0.x for 9.0.32 onwards - 8.5.x for 8.5.52 onwards - 7.0.x for 7.0.101 onwards For reference, the IIS specific attributes will be listed in the docs. CI version available from: https://ci.apache.org/projects/tomcat/tomcat9/docs/config/ajp.html#Standard_Implementations Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Error parsing HTTP request header
Dear Team, We are getting below error in catelina log while starting the tomcat. 26-Feb-2020 18:57:36.795 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 21520 ms 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Will this impact any performance of our tomcat. Thanks & Regards Deepak Kumar CCIL - IT 022-61546230 CIN of CCIL- U65990MH2001PLC131804 "Disclaimer and confidentiality clause - This message and any attachments relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original addressee only. The message may contain information that is confidential and subject to legal privilege. Any views expressed in this message are those of the individual sender. If you have received this message in error, please notify the original sender immediately and destroy the message and copies thereof and any attachments contained in it . If you are not the intended recipient of this message, you are hereby notified that you must not disseminate, copy, use, distribute, or take any action in connection therewith. CCIL cannot ensure that the integrity of this communication has been maintained nor that it is free of errors, viruses, interception and/or interference. CCIL is not liable whatsoever for loss or damage resulting from the opening of this message and/or attachments and/or the use of the information contained in this message and/or attachments."
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Thank you for that - I wasn't sure what patterns were allowed with that attribute, so I couldn't test it. I'll check the isapi_redirect.log to see if it records the exact requests. On Wed, Feb 26, 2020 at 4:01 AM Mark Thomas wrote: > On 25/02/2020 21:47, Ellen Meiselman wrote: > > So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. > > > > But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. > > > > I don’t think this was a problem on the other servers before but the > security has probably been tightened, and it just doesn’t produce an > error - it just won’t allow it. > > > > I have had IIS set to require SSL, but I turned it off to test and it > actually worked all the way through to the simple.html file. so it’s > some sort of policy about downgrading - which seems quite rational in > retrospect > > Thanks for the new information. > > That rules out an issue with the secret settings. > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > unexpected request attributes that is triggering the new protection for > CVE-2020-1938. If that is the case, adding the following to your AJP > connector in server.xml should get things working for SSL as well: > > allowedRequestAttributesPattern=".*" > > Meanwhile, I'll configure my local test environment for IIS with TLS and > see what happens. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 7.0.100
On Wed, Feb 26, 2020 at 12:36 PM Rémy Maucherat wrote: > On Wed, Feb 26, 2020 at 9:57 AM Mark Thomas wrote: > >> On 26/02/2020 01:35, SS jong wrote: >> >> >> >> > Has anyone encountered this issue on Tomcat 7.0.100 and if this >> behavior change is intentional? >> >> Possibly the same root cause as >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 >> > > I can confirm the issue, it is limited to 7.0 as 8.5 is fine. > > Indeed removing the leading "/" in the findResources call works around the > problem. > The fix for the issue will be in 7.0.101. Rémy
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 7.0.100
On Wed, Feb 26, 2020 at 9:57 AM Mark Thomas wrote: > On 26/02/2020 01:35, SS jong wrote: > > > > > Has anyone encountered this issue on Tomcat 7.0.100 and if this behavior > change is intentional? > > Possibly the same root cause as > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 > I can confirm the issue, it is limited to 7.0 as 8.5 is fine. Indeed removing the leading "/" in the findResources call works around the problem. Rémy
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 26/02/2020 09:00, Mark Thomas wrote: > On 25/02/2020 21:47, Ellen Meiselman wrote: >> So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. >> >> But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. >> >> I don’t think this was a problem on the other servers before but the > security has probably been tightened, and it just doesn’t produce an > error - it just won’t allow it. >> >> I have had IIS set to require SSL, but I turned it off to test and it > actually worked all the way through to the simple.html file. so it’s > some sort of policy about downgrading - which seems quite rational in > retrospect > > Thanks for the new information. > > That rules out an issue with the secret settings. > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > unexpected request attributes that is triggering the new protection for > CVE-2020-1938. If that is the case, adding the following to your AJP > connector in server.xml should get things working for SSL as well: > > allowedRequestAttributesPattern=".*" > > Meanwhile, I'll configure my local test environment for IIS with TLS and > see what happens. Confirmed. That is the issue and allowedRequestAttributesPattern=".*" works around it. I need to debug further to find out exactly what the attributes are. I expect we'll add them to the ones Tomcat accepts by default. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hi. I think that we are getting complicated and confusing here. A picture is worth a thousand words, so a little ASCII graphic art may help clarifying things. browser <-(1)-> IIS + proxy <-(2)-> tomcat <-> application - connection (1) can be HTTP or HTTPS (admin choice) - connection (2) can be HTTP, HTTPS, or AJP (admin choice) To simplify, let's say that connection (1) is always HTTPS. In principle, even if connection (1) is HTTPS, IIS should be able to "proxy" the requests to Tomcat over HTTP,HTTPS, or AJP, depending on the configuration of a) IIS itself b) the proxy add-on module inside IIS A) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(AJP)-> tomcat <-> application then : - the proxy module to use in IIS is isapi_redirector - the target Connector/port in tomcat is an AJP connector - AJP is a protocol similar to HTTP/HTTPS, but it is different from them both, and it does not support encryption B) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTP)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. I do not know which one or how to configure it, because I am not an IIS specialist. But it is probably a built-in module in the standard IIS. - the target Connector/port in tomcat is an HTTP Connector - HTTP is not encrypted, but it does not matter very much here, because the connection is only within the same host. C) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTPS)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. same comment as for (B) - the target Connector/port in tomcat is an HTTPS Connector - HTTPS is encrypted, but this is taken care of by the proxy module on the IIS side, and the HTTPS Connector on the Tomcat side. All 3 solutions above are completely equivalent in terms of forwarding (some) requests to tomcat. But maybe something to insist on : only solution (A) above requires isapi_redirector. workers.properties is something which is /only/ used by isapi_redirector, so if you choose solutions (B) or (C), you do not need that file at all. And I do not know if it possible (but presumably it is) to configure IIS to do (B). But that is something for which in principle we cannot help you on this list, because we are not IIS specialists here. Does this make things clearer ? On 26.02.2020 00:17, Ellen Meiselman wrote: Hi Chris, Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. Incoming connections require SSL or will be upgraded to SSL. So if you type in http, it will change to https. Right now because I do not have SSL set as required, I can type in http and it stays http. At that point, it starts working - I no longer get the 403 from Tomcat. My recommendation would be to take this opportunity to switch to HTTPS and dump AJP. OK, I am willing to try - so to do that, would this be the procedure? 1. Set up certificates in Tomcat (big black box for me, but I'll try to figure it out) 2. Change the worker.worker1.type to HTTPS 3. Change the worker.worker1.port to 8443 Anything else? Ellen On Tue, Feb 25, 2020 at 5:47 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, Oops pressed SEND before I was done... On 2/25/20 16:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request to > non-secire AJP. I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. I have had IIS set to require SSL Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect. For example, this HTTP address does work. http://my.servers.domain.com/exposedApplication/simple.html I never tried it because I knew I had set SSL to required. Sometimes you make assumptions that block progress. This HTTPS address does not work - I get the 403 from tomcat. https://my.servers.domain.com/exposedApplication/simple.html So - if this makes sense to any of you, please tell me roughly what I need to do to make the AJP requests as secure as the port 80 requests. Um... I know keystores and .pem files are involved, but please give me the big picture - what port does AJP need to run on, and where do I go to find out how to tell it to use a “real" cert. Traditionally, AJP is run over port 8009 but you can always c
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 25/02/2020 21:47, Ellen Meiselman wrote: > So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. > > But I think I now know where the problem lies. Secure IIS request > to > non-secire AJP. > > I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. > > I have had IIS set to require SSL, but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect Thanks for the new information. That rules out an issue with the secret settings. I wonder if IIS (or more likely the ISAPI redirector) is adding some unexpected request attributes that is triggering the new protection for CVE-2020-1938. If that is the case, adding the following to your AJP connector in server.xml should get things working for SSL as well: allowedRequestAttributesPattern=".*" Meanwhile, I'll configure my local test environment for IIS with TLS and see what happens. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 7.0.100
On 26/02/2020 01:35, SS jong wrote: > Has anyone encountered this issue on Tomcat 7.0.100 and if this behavior > change is intentional? Possibly the same root cause as https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
