On 13/02/2020 19:56, Stefan Mayr wrote: > 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?
AJP is fundamentally different to HTTP. AJP assumes that the client is trusted (and by implication that the network connection between the client and the server is secure). HTTP does not. There has been some discussion around the topic "Should we deprecate support for AJP?" but I don't think we are close to consensus on that. My own view is that while you can use either AJP or HTTP in any situation, there are some situations where one is better suited that the other and for that reason I see us keeping both for now. Might that position change in the future? Maybe, but it looks to be at least a couple of major versions away if it happens at all. > 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? I don't see similar changes ever being made to the HTTP Connector. >> [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? You should see a warning about the unrecognised attribute but it should otherwise be ignored. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
