You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/02/12 12:16:21 UTC
[ANN] Apache Tomcat 9.0.31 available
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.30.
Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.
Apache Tomcat 9.0.31 is a bugfix and feature release. The notable
changes compared to 9.0.30 include:
- AJP defaults changed to listen the loopback address, require a secret
and to be disabled in the sample server.xml
- The JmxRemoteLifecycleListener is now deprecated
- The HTTP Connector attribute rejectIllegalHeaderName is renamed to
rejectIllegalHeader and expanded to include header values as well as
names
Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
Downloads:
http://tomcat.apache.org/download-90.cgi
Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html
Enjoy!
- The Apache Tomcat team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by "André Warnier (tomcat/perl)" <aw...@ice-sa.com>.
On 13.02.2020 11:05, 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.
>
>>
>> (The secret attribute is less of a problem, because as stated in the
>> documentation there is an alternative : secretRequired can be set fo
>> false "when the Connector is used on a trusted network".)
>>
>> Make that such a breaking change in a minor maintenance update is
>> quite touchy. I have never seen such drastic change in my usage
>> history of Tomcat.
>>
For info, there is also another thread entitled "Re: Tomcat 8.5.51 fails", which seems
relevant to this discussion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Stefan Mayr <st...@mayr-stefan.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Olivier Jaquemet <ol...@jalios.com>.
On 13/02/2020 15:31, Christopher Schultz wrote:
> 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
Thank you Christopher for those complements.
And thank you all for your disponibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by logo <lo...@kreuser.name>.
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.
>
> (The secret attribute is less of a problem, because as stated in the
> documentation there is an alternative : secretRequired can be set fo
> false "when the Connector is used on a trusted network".)
>
> Make that such a breaking change in a minor maintenance update is
> quite touchy. I have never seen such drastic change in my usage
> history of Tomcat.
>
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Feb 13, 2020 at 1:04 PM Olivier Jaquemet <
olivier.jaquemet@jalios.com> wrote:
>
> On 13/02/2020 12:41, Mark Thomas wrote:
> > On 13/02/2020 09:57, Olivier Jaquemet wrote:
> >> 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.
> >>
> >> [...]
> > You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour
> > of listening on any address.
> >
> > Mark
>
> Thank you Mark. This should address this use case.
>
> Would you consider adding this binding information to the documentation
> (in the documentation of the address attribute) ?
>
I would say no. These special address values are not specific to Tomcat,
it's like documenting 127.0.0.1 is the IPv4 loopback address [I guess it's
more well known ? hopefully ?].
The address specified on the Connector element goes through
InetAddress.getByName so it's very flexible, it allows more than simple IP
addresses.
Rémy
>
>
> To sum up :
> When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as
> I saw you had also backported this change to the 7.0.x branch),
> if your server architecture is to expose tomcat with an AJP connector,
> to a remote distant front server, you can :
>
> either, *secure your installation* (obviously the recommended way on
> untrusted network) :
>
> - by specifying the valid IP address on which the connector must bind;
> This is done with address attribute of the AJP connector.
>
> - by specifying a shared secret between the front server and the
> connector ; This is done with the secret attribute of the AJP connector
>
>
> or else, if you want your server.xml to be agnostic to the running host
> and remote front server, change your configuration back to the previous
> behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* :
>
> - by removing explicit bind of AJP connector, by specifying "0.0.0.0"
> (IPv4) or "::" (IPv6) in the address attribute of the AJP connector
>
> - by removing need for shared secret between front and tomcat ; This is
> done with the secretRequired="false" attribute of the AJP connector.
>
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Mark Thomas <ma...@apache.org>.
On 13/02/2020 12:04, Olivier Jaquemet wrote:
>
> On 13/02/2020 12:41, Mark Thomas wrote:
>> On 13/02/2020 09:57, Olivier Jaquemet wrote:
>>> 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.
>>>
>>> [...]
>> You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour
>> of listening on any address.
>>
>> Mark
>
> Thank you Mark. This should address this use case.
>
> Would you consider adding this binding information to the documentation
> (in the documentation of the address attribute) ?
The migration guide might be a better place for that sort of thing. Care
to suggest a suitable change to this section:
http://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes
(we can copy the text to the equivalent sections for 8.5.x and 7.0.x)?
> To sum up :
> When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as
> I saw you had also backported this change to the 7.0.x branch),
Correct.
> if your server architecture is to expose tomcat with an AJP connector,
> to a remote distant front server, you can :
>
> either, *secure your installation* (obviously the recommended way on
> untrusted network) :
>
> - by specifying the valid IP address on which the connector must bind;
> This is done with address attribute of the AJP connector.
>
> - by specifying a shared secret between the front server and the
> connector ; This is done with the secret attribute of the AJP connector
>
>
> or else, if you want your server.xml to be agnostic to the running host
> and remote front server, change your configuration back to the previous
> behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* :
>
> - by removing explicit bind of AJP connector, by specifying "0.0.0.0"
> (IPv4) or "::" (IPv6) in the address attribute of the AJP connector
>
> - by removing need for shared secret between front and tomcat ; This is
> done with the secretRequired="false" attribute of the AJP connector.
Correct. Nice summary.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Olivier Jaquemet <ol...@jalios.com>.
On 13/02/2020 12:41, Mark Thomas wrote:
> On 13/02/2020 09:57, Olivier Jaquemet wrote:
>> 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.
>>
>> [...]
> You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour
> of listening on any address.
>
> Mark
Thank you Mark. This should address this use case.
Would you consider adding this binding information to the documentation
(in the documentation of the address attribute) ?
To sum up :
When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as
I saw you had also backported this change to the 7.0.x branch),
if your server architecture is to expose tomcat with an AJP connector,
to a remote distant front server, you can :
either, *secure your installation* (obviously the recommended way on
untrusted network) :
- by specifying the valid IP address on which the connector must bind;
This is done with address attribute of the AJP connector.
- by specifying a shared secret between the front server and the
connector ; This is done with the secret attribute of the AJP connector
or else, if you want your server.xml to be agnostic to the running host
and remote front server, change your configuration back to the previous
behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* :
- by removing explicit bind of AJP connector, by specifying "0.0.0.0"
(IPv4) or "::" (IPv6) in the address attribute of the AJP connector
- by removing need for shared secret between front and tomcat ; This is
done with the secretRequired="false" attribute of the AJP connector.
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Mark Thomas <ma...@apache.org>.
On 13/02/2020 09:57, Olivier Jaquemet wrote:
> 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.
>
> 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 ?
You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour
of listening on any address.
Mark
>
> (The secret attribute is less of a problem, because as stated in the
> documentation there is an alternative : secretRequired can be set fo
> false "when the Connector is used on a trusted network".)
>
> Make that such a breaking change in a minor maintenance update is quite
> touchy. I have never seen such drastic change in my usage history of
> Tomcat.
>
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Olivier Jaquemet <ol...@jalios.com>.
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.
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 ?
(The secret attribute is less of a problem, because as stated in the
documentation there is an alternative : secretRequired can be set fo
false "when the Connector is used on a trusted network".)
Make that such a breaking change in a minor maintenance update is quite
touchy. I have never seen such drastic change in my usage history of Tomcat.
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by "kohmoto@iris.eonet.ne.jp" <ko...@iris.eonet.ne.jp>.
On 2020/02/13 18:32, Rémy Maucherat wrote:
> 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.
>
> The documentation for the new attributes and updated defaults is here:
> http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations
>
Thank you for your advice.
Your advice seems to relate to 9.0 though, could this advice be true
rative to 8.5?
Thank you.
Yours truly,
Kazuhiko Kohmoto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet <
olivier.jaquemet@jalios.com> wrote:
> On 13/02/2020 01:02, Stefan Mayr wrote:
> > Hi,
> >
> >> - AJP defaults changed to listen the loopback address, require a secret
> >> and to be disabled in the sample server.xml
> > What was the motivation behind this breaking change to require a secret
> > or to explitly disable it? What makes an open AJP connector more unsafe
> > than an open HTTP connector?
> >
> > We have hundreds of Tomcats behind Apache httpd with mod_jk. My
> > interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup
> > until we disable the secret in all of them (or add a secret in mod_jk
> > and Tomcat).
> > I would understand that for a new major version 10.x but not in the
> > lifecycle of an existing major version.
>
> Hi,
>
> I second those questions.
>
> We also have many tomcat instances behind Apache HTTPD, most of them are
> not the same server.
> It is my understanding that the new default listening behavior on the
> loopback address would break our installation, as the AJP connector
> would no longer be reachable to our remote Apache HTTP server. It would
> requires that we update all our tomcat's server.xml configuration to
> explicitely listen to an additional address by specifying the "address"
> attribute of the AJP connector.
> 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.
The documentation for the new attributes and updated defaults is here:
http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations
Rémy
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Olivier Jaquemet <ol...@jalios.com>.
On 13/02/2020 01:02, Stefan Mayr wrote:
> Hi,
>
>> - AJP defaults changed to listen the loopback address, require a secret
>> and to be disabled in the sample server.xml
> What was the motivation behind this breaking change to require a secret
> or to explitly disable it? What makes an open AJP connector more unsafe
> than an open HTTP connector?
>
> We have hundreds of Tomcats behind Apache httpd with mod_jk. My
> interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup
> until we disable the secret in all of them (or add a secret in mod_jk
> and Tomcat).
> I would understand that for a new major version 10.x but not in the
> lifecycle of an existing major version.
Hi,
I second those questions.
We also have many tomcat instances behind Apache HTTPD, most of them are
not the same server.
It is my understanding that the new default listening behavior on the
loopback address would break our installation, as the AJP connector
would no longer be reachable to our remote Apache HTTP server. It would
requires that we update all our tomcat's server.xml configuration to
explicitely listen to an additional address by specifying the "address"
attribute of the AJP connector.
Am I correct ? Why such a change ? Why no bugzilla issue for proper
tracking and context ?
What are your recommendations regarding AJP connector configuration ?
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Posted by Stefan Mayr <st...@mayr-stefan.de>.
Hi,
> - AJP defaults changed to listen the loopback address, require a secret
> and to be disabled in the sample server.xml
What was the motivation behind this breaking change to require a secret
or to explitly disable it? What makes an open AJP connector more unsafe
than an open HTTP connector?
We have hundreds of Tomcats behind Apache httpd with mod_jk. My
interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup
until we disable the secret in all of them (or add a secret in mod_jk
and Tomcat).
I would understand that for a new major version 10.x but not in the
lifecycle of an existing major version.
Regards,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org