Hi Chris, Am 13.02.2020 um 15:31 schrieb Christopher Schultz: > [snip] > The answer to the question "why change the default?" is: "because the > default was essentially insecure, in a way that wasn't obvious to > someone who wasn't paying close attention." > > So we are forcing users to pay closer attention. If you want to open > your AJP instance to the "whole world", then you can explicitly bind > to 0.0.0.0/:: just as the previous default. Similarly, if you don't > want to use the "secret" setting, then you can explicitly disable it. > But the defaults will no longer let you be "insecure" without knowing it > . > > Obviously, there are ways to have a "secure" installation while using > 0.0.0.0/:: and/or secretRequired="false". But having those things in > the configuration right in front of you make it clear that some > decision has been made, rather than hiding (potential) danger behind > insecure defaults.
Okay, security is important. I'm a huge fan of secure by default and minimal default setups instead all features enabled. But I still don't understand what makes makes the AJP connector or the protocol itself so insecure. I really don't know much about it. So far this has been a technology that just works for me. Is really AJP the culprit or are you just closing all windows on the "house of tomcat" so everybody has to use the "front door" http? Because if having an open connector is really the argument the http connector would also (by default) have to bind to localhost only. Same as with AJP: you have to make a clear decision in the configuration to open it to the public. Is this something we have to expect in the future? > [snip] > > Will this disrupt some environments? Yes, it will. But the path to > fixing it is to make one (or two) small edits to your configuration > files which are surely under revision-control and automatically > pushed-out to these hundreds-of-nodes clusters everyone is worried > about, right? Well, then, change your configs and push them out there > along with your upgrade of Tomcat and all will be well. > [snip] Automation is the right keyword. Sometimes it is a solution, sometimes this also causes additional problems. In our specific case the configuration management system generates server.xml from templates. Currently it can only use different templates for different major versions (7,8 or 9). Not having tried that yet I would add the new ajp connector parameters in those templates to reflect the old defaults. That would us gain some time to change the configuration management while rolling out new Tomcat versions without breaking things. Now the critical question: will this break the previous versions or will they just ignore unkown parameters? Regards, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
