https://bz.apache.org/bugzilla/show_bug.cgi?id=58750
--- Comment #2 from Mark Thomas <ma...@apache.org> --- I don't see any significant information leakage here, even if the exact Tomcat version is provided. Assume you have a Tomcat instance running 8.0.30 (no known vulnerabilities as I type this). How does it make that instance less secure (easier to attack) if the attacker knows that it is a Tomcat 8.0.30 instance vs. now knowing what server it is? The best answer I can come up with is that the attacker doesn't have to waste time trying out known vulnerabilities for other servers or earlier Tomcat versions but that doesn't make the Tomcat instance any easier to attack. It might mean that the attacker gets spotted and blocked while they test various known vulnerabilities but internet facing servers get hit with so many scans that unless an attacker generates so many requests it starts to have a DoS effect the scans are simply ignored. Automating blocking is only used for the worst offenders because NAT and proxies means blocking every 'attack' shuts out large numbers of legitimate users which is actually much worse than just ignoring the scan. It is also worth noting that because many system admins fake the server header, most attackers try scanning for all known vulnerabilities anyway. Now consider a Tomcat instance running 8.0.0 vulnerable to CVE-2014-0050 (DoS). Hiding the server header doesn't make the Tomcat instance any less vulnerable to the DoS. It may take an attacker slightly longer to find vulnerability, but - given my comments above - they are going to find it anyway. In short, hiding the server header is a waste of time (even for instances running insecure versions) that would be better spend upgrading insecure instances to secure versions. I'd be more than happy to reconsider my position and implement this feature if a valid case is made for how hiding the server header increases the actual security of an instance. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
