At 10:06 PM 5/3/2002, you wrote: > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > At 06:08 PM 5/3/2002, Ian Holsman wrote: > > > > > >On this note what do people think in making the 'default' install only > show the > > >major version (ie.. Apache 2.0) instead of showing everything? > > > > -0 here too... the problem is that a proxy engine, knowing of a specific > > bug with Apache 2.0.41 and prior could compensate for that shortcoming. > > Having no version information means the proxy or other client may be > > unable to accommodate that discrepancy with the HTTP specification. > >How prevalent is that in reality? I mean we allow anybody to bring what >we report down to just major version number, so we really can't expect >proxy servers to use what we report to circumvent problems, can we?
Of course it won't catch them all. That's when you end up with proxy failure errors. The point is that a proxy _could_ correct for a bad server if it knew what to expect. Take certain flaws in IIS's implementation. Recognized, they can be worked around. Unrecognized, the proxies of the world will simply throw up. Big deal. There's another aspect to this debate. It isn't impossible to come up with heuristics that describe a given server (based on header presence, absence, order of headers, capitalization, and even bug results.) This can be down to the specific sub revision or service pack level, depending on how the behavior has been altered. IMHO - it's fruitless to "mask" the identity of the HTTP protocol software. Brute force attacks will still succeed against vulnerable servers, no matter what their identity reveals. However, there is _no_ discrepancy in MPM responses, except for very subtle timing disparities. It's the same server. So I don't see how identifying the HTTP server, but not disclosing the MPM would contract each other. Denial of Service isn't a one-shot, it may take a sustained effort. So an MPM's vulnerability could be disclosed for targeted, explicit exploit. Just my 2c (US). Bill
