-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Peter,

On 2/13/20 5:05 AM, logo wrote:
> 
> 
> Am 2020-02-13 10:57, schrieb Olivier Jaquemet:
>> On 13/02/2020 10:32, Rémy Maucherat wrote:
>>> On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote:
>>>> On 13/02/2020 01:02, Stefan Mayr wrote:
>>>>>> - AJP defaults changed to listen the loopback address,
>>>>>> require a secret and to be disabled in the sample
>>>>>> server.xml
>>>>> [snip]
>>>> Am I correct ? Why such a change ? Why no bugzilla issue for
>>>> proper tracking and context ? What are your recommendations
>>>> regarding AJP connector configuration ?
>>> It is obviously best to keep default configurations as stable
>>> as possible. But sometimes things have to change ... As a
>>> result, you'll indeed need to adjust your server.xml according
>>> to your deployment and AJP usage.
>> 
>> Thank you Rémy for taking the time to answer.
>> 
>> I understand the need to introduce a "secured by default" AJP 
>> configuration. However, I question one choice that was made for
>> this change : the default behavior of the AJP connector to listen
>> only on the loopback address.
>> 
> 
> +1
> 
>> This is the change which is, to me, the most questionable one.
>> Because to my understanding, any architecture in which a remote
>> Apache HTTPD is being used will require a *specific IP address of
>> the current host* to be specified in the address attribute of the
>> AJP connector. A specific IP address means that the server.xml is
>> no longer agnostic to the platfom it is being hosted on. Prior to
>> this, a server.xml file could be configured in such way that it
>> would never contain any hard coded value related to the current
>> host. With this change it is no longer possible. (unless I'm
>> missing something). For large deployment configuration, this does
>> seems a bit problematic. Do you understand my concern ? Is there
>> any way to address this ?
> 
> That's really difficult. Specifically in container environments
> where the container is started dynamically and the ip address
> shifts frequently. Access is done through dns or labels.

My question would be "why do so many have AJP connectors where no
'address' attribute was specifically configured?"

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.

Why make this change in a point-release and not a major one? Because
we felt it was important enough to do so.

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.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5FXaMACgkQHPApP6U8
pFgTYw/+IjsZW/64GZlOTuH2AcQALHGXrEfjSxQqmtG40DefwJegg6PbxwZFenJg
b9lns+vgq7SGmVWbOG8loVJg4yos6d5B2dIkwTD9KFIJU14xygSCkEMwLimP7Syi
lyFR90wH5+2rI5bpP1Iir9Ybt2+GBGPjzkcmRHNb+5E3xikfpZ3g5kE41mey+Y/A
Zx/R8CAqnSw161JMKysRrV4Jm+a30r3YQyll5m2CiGvP2zEc6gt4loQVXG0/ngQH
qUQOk1FMyUdRFgg6fKrm0uHaWyUxt+kNXkEC9d6oEAVziftGKmn91qkb+ywRFgme
hI/JJK+d2OKqXlj2OLHuZLPTojodOEckRzy4vArbSTnAAYO9f3xkb/DBqxYQSOk+
WFFbGYvgGtuwzmu3lliAPVNvUwMLqyu7aBfxDEugttHiwPh4bZUK7CxSoStHhda2
w8qqldItJC3dsxUw+u8czP/JSb1JR93lwo3/ryWIMJHMC0aECdv3W+Um87kjrGF9
FdNgevEmrhNlCBzARK/xJaVb3oHclHi6HRg7nIGdSsvNrrOqTgRCaAVQD/TFSYWh
Ej5x10Ai0MPZfy+4xqiedpc4Tw7sj6JLNBoXDxwlOhZhX4en31p0xuDdgqs6ScWS
ostbxlUJtQHVTa53mFca/yzj0OTDs8Xq/dNOr0y0hnl2UIR9IKY=
=0DJu
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to