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 <jonmcalexan...@wellsfargo.com.invalid> > wrote: > >> -----Original Message----- >>> From: Mark Thomas <ma...@apache.org> >>> 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
