Stafan,
On 2/13/20 14: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?
If you use the HTTP connector, you can use TLS. There is no TLS
equivalent for AJP. If you have your proxy on localhost, then there is
minimal danger (and you can bind to 127.0.0.1 safely, so no problem). If
your proxy is elsewhere, you *really should* be using HTTPS (for HTTP)
or something like stunnel. If you are using stunnel, then localhost
binding is again what you want.
It's much more obvious when you look at the HTTP connector and say "hey,
that doesn't gave any TLS config on it -- let's fix that". AJP is a
magic mystery to lots of people and they may think that because it's
binary, it's secure. It is not.
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?
The AJP connector also trusts the incoming connection in a way that the
HTTP connectors do not. For example, you need to configure the
RemoteIPValve[1] if you want to inherit the client's IP address for
things like log files when using HTTP, but you get it "for free" with
AJP. Making the decision to add the RemoteIPValve is a security choice
that you don't get to make with AJP -- that choice is made for you and
you can't turn it off.
So it's best to force users to make security choices that they actually
know about, instead of us making those choices for them in ways that can
be potentially harmful. Maybe not hideously harmful... wrong IPs in your
log file? Maybe not a huge deal for you. But for others, it may cause a
violation of a required security control.
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?
It's safe to put it in now, in preparation for a future upgrade.
-chris
[1]
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
