Hello httpd docs @ Apache Software Foundation,
I am writing this e-mail to learn more about ASF attitude towards presenting or hiding httpd server version details in headers. I have read the FAQ and documentation and agree with some statements and disagree with most. That is why I would like to have it clarified. Both in FAQ[1] and in documentation[2] it is discouraged to obscure the details of httpd server. The rationale provided is that (all are quotations from [1] and [2]): Arg1: It does nothing at all to make your server more secure Arg2: The idea of "security through obscurity" is a myth and leads to a false sense of safety Arg3: mistaken understanding that this will make the system more secure Arg4: the same exploits will likely be attempted regardless of the header information Arg5: it makes it more difficult to debug interoperational problems I have checked the reccomendation from OWASP[3] and they advise to remove or alter the headers so that no unnecessary details are presented. I tend to subscribe to owasp's point on view and would like to elaborate on it so that we can argue more precisely and reach meaningful conclusions. If we were to experience a targeted cyber attack against our servers it is certain that criminals would launch a battery of exploits against our assets and presence/absence of headers would change nothing about it. This supports your Arg4. Moreover, even if misleading data was presented to a determined attacker this would not make them narrow their arsenal. This seems to support arguments 1,2,3, and 4. But not all attacks are targeted. If malicious actors have at their disposal an exploit that works on a given version of software they would probably first assemble a list of potential victims. Showing too much in one's headers can lead to appearing on the list or not. Not appearing on the list is in my opinion a valid way of cyber defense. It should not be named 'security by obscurity' as long as it is not THE ONLY means of defence taken. Cybersecurity is a multi-layer problem. This undermines arguments 1,2,3 and to some extent argument 4. What is left to tackle from rationale provided is argument 5 - debugging. I would split debugging into two categories: internal and external. An engineer that is debugging internally should have access to some CMDB systems to learn what system they are dealing with, what are the version and who is the owner/administrator so that they can ask them any burning questions. I agree that this adds some extra steps to debugging but in my (and owasp's) opinion it is not the sweet spot where we should give up some security to gain some debugging ease. If we are dealing with external debugging in many cases this would fulfill the definition of a cyber attack. What I would like to achieve with this e-mail? I would like you to share your opinions on my argumentation against statements in docs and FAQ. If you agree with what I write I would like to have those statements[1,2] changed. If needed I can propose the change – in this case I would need some guidance on how to do this and how to request necessary access. Why it matters for me? I am a security engineer trying to convince some other teams to hide unnecesary information from headers. They rejected my request using ASF statements as a rationale. I respect the authority ASF has earned in the tech world and would rather discuss with you problems I run into rather than state myself that we should act in opposition to what is written in ASF documents. Let's do it the Apache way[4]! Thank you in advance, [1] https://cwiki.apache.org/confluence/display/httpd/FAQ#FAQ-HowcanIchangetheinformationthatApachereturnsaboutitselfintheheaders? [2] https://httpd.apache.org/docs/2.4/mod/core.html#servertokens [3] https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server [4] https://apache.org/theapacheway/index.html Piotr Sionkowski Senior Application Security Engineer GSK ul. Pastelowa 2, Business Garden, 60-198 Poznan, Poland Email piotr.g.sionkow...@gsk.com<mailto:piotr.g.sionkow...@gsk.com> gsk.com<http://www.gsk.com/> | Twitter<http://twitter.com/GSK> | YouTube<http://www.youtube.com/user/gskvision> | Facebook<http://www.facebook.com/glaxosmithkline> | Flickr<http://www.flickr.com/photos/glaxosmithkline> [signature_998159052] GSK monitors email communications sent to and from GSK in order to protect GSK, our employees, customers, suppliers and business partners, from cyber threats and loss of GSK Information. GSK monitoring is conducted with appropriate confidentiality controls and in accordance with local laws and after appropriate consultation.
