despite setting in server.xml <Connector port ... server="NameThatIsNotInterestingForAnAttacker" org.apache.catalina.util.ServerInfo in org.apache.catalina.valves.ErrorReportValve.report() prints Apache Tomcat/8.5.47 (Ubuntu) please also respect the abvor "server" setting here !
As far as I can see, you are using a non-official Tomcat distribution. Please complain with your OS provide or use our binary tarballs.
Hi Michael, Thanks for your comment. "Apache Tomcat/8.5.47 (Ubuntu)" is not the true version and OS I am using, this is just for illustration purpose. also "official Tomcat distributions" seem to have this problem. thx Ralf
(In reply to Ralf Hauser from comment #2) > Hi Michael, > > Thanks for your comment. > > "Apache Tomcat/8.5.47 (Ubuntu)" > > is not the true version and OS I am using, this is just for illustration > purpose. > > also "official Tomcat distributions" seem to have this problem. > > thx Ralf Why don't you then provide real, complete data? You haven't read the right documentation. server attribute is not for the ErrorReportValve. Read the docs for that valve and you can solve yor problem within 5 min. BTW, this is merely security by obscurity -- a common misconception.
(In reply to Ralf Hauser from comment #2) > Hi Michael, > > Thanks for your comment. > > "Apache Tomcat/8.5.47 (Ubuntu)" > > is not the true version and OS I am using, this is just for illustration > purpose. > > also "official Tomcat distributions" seem to have this problem. > > thx Ralf http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Error_Report_Valve showReport=false showServerInfo=false Isn’t this enough? Regards Violeta
Hi Violeta, Sure, showServerInfo=false achieves a similar goal, but why not be consistent with the "server" attribute of server.xml ?
(In reply to Ralf Hauser from comment #5) > Hi Violeta, > > Sure, > showServerInfo=false > achieves a similar goal, but why not be consistent with the "server" > attribute of server.xml ? Because both serve a different purpose -- obviously.
The tone of some of the comments on this issue is getting a little unfriendly. I'd ask that everyone remind themselves of the ASF code of conduct - particularly guideline 2: "Be empathetic, welcoming, friendly, and patient." Thanks.
(In reply to Ralf Hauser from comment #5) > showServerInfo=false > achieves a similar goal, but why not be consistent with the "server" > attribute of server.xml ? There are some subtle differences. The server header, if set, gets sent on every response. It isn't many bytes but neither does it add much value. The consensus opinion is currently to disable by default (but not for security reasons although disabled by default does make some security folks happy). The server info in the error report valve only gets sent when there is an unhandled error. In that scenario it is more likely to be useful (it might help track down an existing bug report for the issue). The consensus opinion is, therefore, to default to enabled. Some security folks don't like this so there is the option to disable it. Keep in mind that Tomcat is used in a wide range of scenarios from local development to large scale production deployments. There is no one configuration that fits all use cases so we try and provide one that is a good starting point for more uses that users can then tweak as required. What there might be a case for is if "server" is explicitly set on the Connector then use the same value in the ErrorReportValve although I'm not sure the added code/complexity is worth the benefit.
Every penetration tester will complain about it. If they can be made happy in one go, that would be great. In the current setup, they in most cases will have two points to raise...
(In reply to Mark Thomas from comment #7) > The tone of some of the comments on this issue is getting a little > unfriendly. > > I'd ask that everyone remind themselves of the ASF code of conduct - > particularly guideline 2: > > "Be empathetic, welcoming, friendly, and patient." > > Thanks. +1
(In reply to Mark Thomas from comment #8) > (In reply to Ralf Hauser from comment #5) > > showServerInfo=false > > achieves a similar goal, but why not be consistent with the "server" > > attribute of server.xml ? > > There are some subtle differences. > > What there might be a case for is if "server" is explicitly set on the > Connector then use the same value in the ErrorReportValve although I'm not > sure the added code/complexity is worth the benefit. I'd be against such high coupling of components...
(In reply to Ralf Hauser from comment #9) > Every penetration tester will complain about it. > If they can be made happy in one go, that would be great. > In the current setup, they in most cases will have two points to raise... Same recommended me to upgrade to 9.0.x from 8.5.x because it is the "best" available version -- nonsense.
(In reply to Ralf Hauser from comment #9) > Every script kiddie pen tester will complain about it. FTFY
I'm leaning towards resolving this as WONTFIX. The server attribute defaults to null whereas ServerInfo (as used in the ErrorReportValve and other places) defaults to "Apache Tomcat/<version>". I don't see any easy way to tie these settings together that doesn't essentially change the default of one of them and that goes against what I understand to be the current consensus opinion.
Securing Apache Tomcat 8.5.x is documented at [1]. Both "server" attribute and ErrorReportValve are documented there. BTW, there is a typo in [1]. Its description of the default value "server" attribute in [1] does not match the configuration reference [2]. ([1] says it is "Apache-Coyote/1.1", [2] says it is none.) > I'm leaning towards resolving this as WONTFIX. +1 If one were to define a place to configure a server description then I think that it would be at some container level (Host/Service/Server) or in catalina.properties file, as a replacement for the current way of customizing ServerInfo.properties file. If server.info property of ServerInfo.properties file were exposed as a system property (maybe by a custom PropertySource), one could write <Connector server="${server.info}"> to have the same value as displayed by ErrorReportValve. But actually I think that nobody wants such feature. (The attribute "server" on a Connector is a protocol option for HTTP/1.1 for one the headers defined by that protocol. It is a wrong place to define a server-wide value. The Connector for AJP protocol [3] does not have such option.) [1] https://tomcat.apache.org/tomcat-8.5-doc/security-howto.html [2] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html [3] https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html
(In reply to Mark Thomas from comment #14) > I'm leaning towards resolving this as WONTFIX. +1 > The server attribute defaults to null whereas ServerInfo (as used in the > ErrorReportValve and other places) defaults to "Apache Tomcat/<version>". Similar to the (ahem) HTTP status reason phrase, these things serve two different use-cases: one of them -- the "Server" response header -- is intended to be read by client software and used for decision making, statistics, etc. The other -- the footer of error pages -- is intended to be read by humans. (In reply to Konstantin Kolinko from comment #15) > If server.info property of ServerInfo.properties file were exposed as a > system property (maybe by a custom PropertySource), one could write > <Connector server="${server.info}"> to have the same value as displayed by > ErrorReportValve. But actually I think that nobody wants such feature. This would kind of be the best way to do this. It allows you to at least configure the value in a single place and have it "copied" around to the other places, if that's what you want. But ... really, this isn't that big of a deal. > (The attribute "server" on a Connector is a protocol option for HTTP/1.1 for > one the headers defined by that protocol. It is a wrong place to define a > server-wide value. The Connector for AJP protocol [3] does not have such > option.) But it's not a server-wide value. The AJP connector doesn't have it because by definition it's being used by a proxy. The proxy supplies its own "Server" header.
I've fixed the docs (thanks Konstantin) and, based on the +1's, I am resolving this as WONTFIX.