Hi, On Tue, Mar 10, 2020 at 10:00 AM "Jürgen Göres" <jg...@gmx.de> wrote:
> > > Hi Mark, > > so I went with your proposed default setting of "::". > Alas, this fails, e.g., when we put our Tomcats into Docker containers, > where only IPv4 is available (I would expect the same to happen on AWS > environments, which are usually IPv4 only, too, haven't checked that yet): > > 10-Mar-2020 04:07:58.435 INFO [main] > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler > ["ajp-nio-0:0:0:0:0:0:0:0-8009"] > 10-Mar-2020 04:07:58.449 SEVERE [main] > org.apache.catalina.core.StandardService.initInternal Failed to initialize > connector [Connector[AJP/1.3-8009]] > org.apache.catalina.LifecycleException: Protocol handler > initialization failed > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1032) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > [...] > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) > at java.base/java.lang.reflect.Method.invoke(Unknown > Source) > at > org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:303) > at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473) > Caused by: java.net.SocketException: Protocol family unavailable > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Unknown Source) > at java.base/sun.nio.ch.Net.bind(Unknown Source) > at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(Unknown > Source) > at java.base/sun.nio.ch.ServerSocketAdaptor.bind(Unknown > Source) > at org.apache.tomcat.util.net > .NioEndpoint.bind(NioEndpoint.java:221) > at org.apache.tomcat.util.net > .AbstractEndpoint.init(AbstractEndpoint.java:1118) > at org.apache.tomcat.util.net > .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:223) > at > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:587) > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1030) > ... 13 more > > So this means that I need to set the value to "::" in dual stack or pure > IPv6 environments, while it seems that I have to use 0.0.0.0 in IPv4-only > environments. > I would therefore need to put some possibly fragile logic into various > places in my startscripts (we have start scripts actually using Ant in our > custom deployment solution, and for Docker we use bash) that determines the > available IP versions, since I want to have as little config hazzle as > possible for customers. > I would rather avoid that and have a way to get back the old behaviour. > Some of our apps are spring-boot-based with an embedded Tomcat. Here, we > can just set the address to null in the programmatic configuration of > the AJP connector that we created (spring boot has no built-in AJP support) > and we seem to have the old behavior back. > What we would need for Tomcats that are configured in the conventional way > (i.e., server.xml) is to have a string value for the address attribute that > translates to a null value for the bind address. > Setting the address attribute to the empty string gives me "loopback only" > behaviour. How about "*" to get back the old behavior? > https://github.com/apache/tomcat/commit/aba0c9a488a7d7e5063779e88f652cdca439cd24#diff-1e6fe5c59fc0bfbbababbb0ce53621a9 this is the change to loopback address. Before that it was creating a ServerSocket without InetAddress, i.e. bind on 0.0.0.0, i.e. on all network interfaces. If you use address="0.0.0.0" it will return the old behavior. You may want to add some firewall rules to define who can reach the AJP port and on which interfaces. Unless you have those already, of course. > Regards > > J > > > > > > Gesendet: Donnerstag, 05. März 2020 um 09:34 Uhr > > Von: "Mark Thomas" <ma...@apache.org> > > An: users@tomcat.apache.org > > Betreff: Re: Aw: Re: Fix for CVE-2020-1938 > > On 05/03/2020 07:12, "Jürgen Göres" wrote: > > > > >>> My first question is: what value do I need to set in the "address" > attribute to indicate that I want the connector to listen on ALL interfaces > (for IPv4 AND IPv6)? Maybe that should be documented. :-) > > >> > > >> It will vary by system. Some systems can't listen on both IPv4 and > IPv6 > > >> with a single socker. Usually either "::" or "0.0.0.0" will have the > > >> desired result. > > > > > > That is a bit of a problem for us. In the environments we support (Win > and Linux), from my observation the connectors would successfully bind to > both IPv4 and IPv6 addresses. Since we have customers that use either IPv4, > IPv6, or both and often have multiple interfaces on their machines, we > cannot know which address/interface (or even which IP version) to bind to. > And up to now, we didn't have to worry about it. > > > Now our installation routine would somehow need to find out whether it > should put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero > conf" for us so far now suddently becomes a new source for problems > (=customer calls). > > > Is there no way to optionally configure the old binding behaviour for > the AJP connector? > > > > Let me re-phrase. > > > > Usually, for the NIO and NIO2 Connectors, specifying "::" or "0.0.0.0" > > will result in the server socket binding to all IPv4 and IPv6 addresses. > > > > For APR/Native, "0.0.0.0" will be IPv4 only. "::" will be IPv4 and IPv6. > > > > If the underlying OS does not support "dual stack" networking (most do), > > "0.0.0.0" will result in listing on all IPv4 addresses and "::" will > > result in listening on all IPv6 addresses. > > > > For your use case "::" looks like the best default. > > > > Most of this is in the docs for the HTTP Connector. I'll add the same > > text to the AJP Connector. > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
