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 <ma...@apache.org> 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 > >
