Re: vote on concept of ServerTokens Off
Jim Jagielski wrote: > Sounds like 3 years have not changed the feelings towards > this. Ideally, we should remove the whole ap_get_server_version/ > ap_get_server_banner re-work as well since, iirc, this was > all to make it easier for this exact type of change. ---1! (whoops, that's zero :) Seriously, you remember when ServerTokens was introduced to strip the rev numbers... well this split of functionality has provided us much richer error.log results to diagnose issues, when the admin doesn't even know wfv they are running. That function split re-introduced details that were missing from the error log, before. > In any case, I'll revert as soon as I have some cycles. Thanks
Re: vote on concept of ServerTokens Off
On Wed, Sep 9, 2009 at 4:07 PM, Jim Jagielski wrote: > Sounds like 3 years have not changed the feelings towards > this. Ideally, we should remove the whole ap_get_server_version/ > ap_get_server_banner re-work as well since, It is generally useful to separate what information we write to arbitrary clients (controlled by ServerTokens) vs. what is logged at startup or reported in a few other special places; also, such a change would break binary compatibility. > iirc, this was > all to make it easier for this exact type of change. > yes, in that without the version-vs-banner change, "ServerTokens Off" would have taken an unfortunate behavior to a nonsensical extreme; but trimming the amount of information logged at startup based on ServerTokens was a known concern (at least it was one of my pet peeves)
Re: vote on concept of ServerTokens Off
Sounds like 3 years have not changed the feelings towards this. Ideally, we should remove the whole ap_get_server_version/ ap_get_server_banner re-work as well since, iirc, this was all to make it easier for this exact type of change. In any case, I'll revert as soon as I have some cycles.
Re: vote on concept of ServerTokens Off
Lars Eilebrecht wrote: > > My apologies for not responding earlier, but I was busy moving from > Munich to London last week ... Understandable, congratulations on what I hope was a successful move, thanks for responding today. > As far as I remember, Mads Toftum also voted with a -1. Yes; although Mads is neither a committer nor PMC member, there have been several other votes from the peanut gallery for and against, some tepid and some strong opinions. I was trying to distill the list to binding votes to reach a conclusion. > My -1 hasn't changed as I still feel very strongly about this for reasons > already discussed back in 2006 (and once in 2004 or 2005 when the > same discussion came up). Thank you for clarifying. > Given two -1s and many people voting -0 I'm wondering why we are still > discussing this topic? Ask Jim? Only one binding -1, yours still, and a majority (as you saw in the summary) voting +1 for the patch. Many of those individuals are active in triaging issues.a.o, users@ etc, and I see their rational. In fact, it refined my objection to be nominally +0.5 for the 'Off' behavior, while strongly -1.0 for any 'Set' behavior that represents Apache httpd as anything other than Apache httpd, which was also modified a couple weeks ago. > P.S.: I'm not sure what you mean with "hasn't responded in 21 months"? > I voted in 2006 on this topic and then you picked up this thread > last week? There were a few more days of activity you ignored back then, including posts to you from Jeff and Jim. Thanks for straighting us out :)
Re: vote on concept of ServerTokens Off
On Wed, Sep 9, 2009 at 5:39 AM, Lars Eilebrecht wrote: > William A. Rowe, Jr. wrote: > > > Except that in this case, between Lars offer to "ignore" his vote/veto, > and > > the fact that he hasn't responded in 21 months (I also emailed him > directly > > last week to ensure he made note of this thread), he apparently does not > > feel strongly enough to either confirm his veto, or confirm his > willingness > > to be talked out of this veto. Jeff asked for explicit confirmation or > > retraction of this veto on Dec 6th 2006, and Lars had not responded, so > it > > appears we can move ahead as this statement above appeared to be half-way > > retracted veto, and he's unwilling to comment further to either agree > with > > Jim, or explicitly vote -0/distasteful. > > My apologies for not responding earlier, but I was busy moving from > Munich to London last week ... > > As far as I remember, Mads Toftum also voted with a -1. > My -1 hasn't changed as I still feel very strongly about this for reasons > already discussed back in 2006 (and once in 2004 or 2005 when the > same discussion came up). > > Given two -1s and many people voting -0 I'm wondering why we are still > discussing this topic? > Because somebody committed code to disable Server or set it to an arbitrary value... *) ServerTokens now accepts 'Off' which disables sending of Server: header and sets SERVER_SOFTWARE to empty. It also accepts 'Set' which allows the user to specify any string as the Server: name.
Re: vote on concept of ServerTokens Off
William A. Rowe, Jr. wrote: > Except that in this case, between Lars offer to "ignore" his vote/veto, and > the fact that he hasn't responded in 21 months (I also emailed him directly > last week to ensure he made note of this thread), he apparently does not > feel strongly enough to either confirm his veto, or confirm his willingness > to be talked out of this veto. Jeff asked for explicit confirmation or > retraction of this veto on Dec 6th 2006, and Lars had not responded, so it > appears we can move ahead as this statement above appeared to be half-way > retracted veto, and he's unwilling to comment further to either agree with > Jim, or explicitly vote -0/distasteful. My apologies for not responding earlier, but I was busy moving from Munich to London last week ... As far as I remember, Mads Toftum also voted with a -1. My -1 hasn't changed as I still feel very strongly about this for reasons already discussed back in 2006 (and once in 2004 or 2005 when the same discussion came up). Given two -1s and many people voting -0 I'm wondering why we are still discussing this topic? P.S.: I'm not sure what you mean with "hasn't responded in 21 months"? I voted in 2006 on this topic and then you picked up this thread last week? cheers... -- Lars Eilebrecht l...@apache.org
Re: vote on concept of ServerTokens Off
William A. Rowe, Jr. schrieb: > Guenter, please confirm if you are casting a veto, or in light of this > earlier discussion and rationale, you are just expressing your standing > distaste for the patch (which is -0)? -0 Gün.
Re: vote on concept of ServerTokens Off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William A. Rowe, Jr. wrote: > > Guenter, please confirm if you are casting a veto, or in light of > this earlier discussion and rationale, you are just expressing your > standing distaste for the patch (which is -0)? For the record, I also agree with Lars' and Guenter's rationale, and also vote -0 Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnQmgACgkQ7bEFiW+VIthV3ACfSbQzayQsCrYNEOQJqCMS6E3z 2igAoJE/8bUyjhJAiVor4M7ArtLXcqoS =nLpa -END PGP SIGNATURE-
Re: vote on concept of ServerTokens Off
William A. Rowe, Jr. wrote: > Guenter Knauf wrote: >> Hi, >> William A. Rowe, Jr. schrieb: >>> Jim Jagielski wrote: Lars Eilebrecht wrote: > According to Jeff: > >> A lot of opinions were offered back in August. Some were negative but >> I don't see anything that looks like a veto. > I voted -1 at that time which is a veto. > > My opinion hasn't changed and I still think that it is a very > stupid idea to add a "feature" that allows our users to do > something which is stupid and absurd. > > *shrug* but as everyone seems to think that this is a good idea, > feel free to ignore my veto. A Veto is a Veto. If you feel strongly enough about it, then it cannot be, and should not be, ignored. Except that in this case, between Lars offer to "ignore" his vote/veto, and the fact that he hasn't responded in 21 months (I also emailed him directly last week to ensure he made note of this thread), he apparently does not feel strongly enough to either confirm his veto, or confirm his willingness to be talked out of this veto. Jeff asked for explicit confirmation or retraction of this veto on Dec 6th 2006, and Lars had not responded, so it appears we can move ahead as this statement above appeared to be half-way retracted veto, and he's unwilling to comment further to either agree with Jim, or explicitly vote -0/distasteful. >> If we would vote now, I would vote against. It makes no sense at all, >> and folks who believe that hiding ServerTokens would make their server >> more secure or relax the requirement to update for security bugfixes are >> complete idiots who have never looked into their server logs. > > That was not the only point raised in the Server: toggle off debate. The > major reason was to trash all the bug reports and user queries about this > issue, which show up daily at #httpd and several times a month on us...@. > It's a distraction that helpful peers should not need to keep answering. > > And the other minor point was applications where the user wanted to save > the bandwidth handful of bytes per response. Not compelling justification, > but not a nonsensical request (unlike "how do I protect my server by...") Guenter, please confirm if you are casting a veto, or in light of this earlier discussion and rationale, you are just expressing your standing distaste for the patch (which is -0)? >> Also, I think we have some new folks here who also might want to vote, >> and we should probably vote again? > > And if they want to, they will. There is a thread, though it's two years > old. No need to start a new vote/thread. There were an overwhelming > number of votes in favor, so other than outstanding vetoes, there is no > reason not to finish ServerTokens Off if someone like Jim or Jeff just > comes along and commits it [if and once Lars lifted his veto]. And I've seen no other votes. 'Set' is clearly vetoed (it makes no sense to falsely advertise Apache as anything other than Apache, and legitimate purposes can be served with an 'Add' feature), while it looks like 'Off' survives, depending now upon Guenter's vote. The +1 votes are trawick, jorton, slive, jim, rpluem, stoddard, fielding; we have -0 from wrowe, niq, and jerenkrantz, a half-way retracted veto from Lars, and Guenter's threat of veto. If Guenter and/or Lars would clarify, we could put this discussion thread to bed, and call the patch signed sealed and delivered or revert it [although the argument has been made that there are not technical grounds for such a veto to stand on]. In the interim, Jim, could you kindly replace the 'Set' functionality with 'Add' to work around the less flexible veto from last week, or simply revert it already? Bill
Re: vote on concept of ServerTokens Off
Guenter Knauf wrote: > Hi, > William A. Rowe, Jr. schrieb: >> Jim Jagielski wrote: >>> Lars Eilebrecht wrote: According to Jeff: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. I voted -1 at that time which is a veto. My opinion hasn't changed and I still think that it is a very stupid idea to add a "feature" that allows our users to do something which is stupid and absurd. *shrug* but as everyone seems to think that this is a good idea, feel free to ignore my veto. >>> A Veto is a Veto. If you feel strongly enough about it, then >>> it cannot be, and should not be, ignored. >> Lars, >> >> yours is the last veto standing for ServerTokens Off. What say you? >> >> (Your veto would appear to imply a veto of any ServerTokens Set syntax). > > If we would vote now, I would vote against. It makes no sense at all, > and folks who believe that hiding ServerTokens would make their server > more secure or relax the requirement to update for security bugfixes are > complete idiots who have never looked into their server logs. That was not the only point raised in the Server: toggle off debate. The major reason was to trash all the bug reports and user queries about this issue, which show up daily at #httpd and several times a month on us...@. It's a distraction that helpful peers should not need to keep answering. And the other minor point was applications where the user wanted to save the bandwidth handful of bytes per response. Not compelling justification, but not a nonsensical request (unlike "how do I protect my server by...") > Also, I think we have some new folks here who also might want to vote, > and we should probably vote again? And if they want to, they will. There is a thread, though it's two years old. No need to start a new vote/thread. There were an overwhelming number of votes in favor, so other than outstanding vetoes, there is no reason not to finish ServerTokens Off if someone like Jim or Jeff just comes along and commits it [if and once Lars lifted his veto].
Re: vote on concept of ServerTokens Off
Guenter Knauf wrote: > [snip] > Finally, I would even like to suggest something opposite: let the > user/admin add a configurable ServerToken with something like > AddServerToken "String"; I have already years ago hacked such a module > which is very useful in load balance environments in order to see which > server actually served the request. > > Gün. > That's easy. Use mod_headers and add an X-Origin-Server header That's what I always do
Re: vote on concept of ServerTokens Off
Hi, William A. Rowe, Jr. schrieb: > Jim Jagielski wrote: >> Lars Eilebrecht wrote: >>> According to Jeff: >>> A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. >>> I voted -1 at that time which is a veto. >>> >>> My opinion hasn't changed and I still think that it is a very >>> stupid idea to add a "feature" that allows our users to do >>> something which is stupid and absurd. >>> >>> *shrug* but as everyone seems to think that this is a good idea, >>> feel free to ignore my veto. >> A Veto is a Veto. If you feel strongly enough about it, then >> it cannot be, and should not be, ignored. > > Lars, > > yours is the last veto standing for ServerTokens Off. What say you? > > (Your veto would appear to imply a veto of any ServerTokens Set syntax). If we would vote now, I would vote against. It makes no sense at all, and folks who believe that hiding ServerTokens would make their server more secure or relax the requirement to update for security bugfixes are complete idiots who have never looked into their server logs. I see tons of attacks on my Apache servers where scripts check for each and every IIS exploit, so certainly those exploit scripts dont care at all for what the server claims to be; also if a script wants to exploit an APR bug then it cant rely on Apache ServerTokens since they dont tell about APR version, and 2.2.x can run with a bunch of different 1.2.x and 1.3.x APR versions. Also, I think we have some new folks here who also might want to vote, and we should probably vote again? Finally, I would even like to suggest something opposite: let the user/admin add a configurable ServerToken with something like AddServerToken "String"; I have already years ago hacked such a module which is very useful in load balance environments in order to see which server actually served the request. Gün.
Re: [Fwd: Re: vote on concept of ServerTokens Off]
I'm not too fond of being able to remove it either. It can always be set to "Apache" with the current configuration options and that should keep people worried about exploits somewhat satisfied. Even if you where able to hide it completely a good script could figure out if it's a 1.3 2.0 or 2.2 based on how it handles retain requests and on the Directory listing for example. As ~Jorge On Tue, Sep 1, 2009 at 11:36 PM, William A. Rowe, Jr. wrote: > Why attach email doesn't work in thunderbird is beyond me... > > This was Jeff's starting point for documenting ServerTokens Off. > > > ---- Original Message ---- > Subject: Re: vote on concept of ServerTokens Off > Date: Wed, 6 Dec 2006 13:43:49 -0500 > From: Jeff Trawick > Reply-To: dev@httpd.apache.org > To: dev@httpd.apache.org > References: <200612061412.kb6ecwb10...@devsys.jagunet.com> > > > <4576f73a.3020...@force-elite.com> > > On 12/6/06, Paul Querna wrote: > >> This thread is making me sad. > > No tears ;) The somewhat bright side is that pushing on this tender > spot until it hurts should at the very least avoid having the same > discussion here for the next couple of years, and at the most can > avoid a lot of other wasteful discussions permanently ;) The middle > ground of document explicitly why you can't directly turn it off > should also be achievable. > > Proposed documentation for the ServerTokens directive. > > Special note: > > Apache HTTP Server users suggest from time to time that the > ServerTokens directive allow the Server response header to be > eliminated completely. This feature suggestion is rejected for the > following reasons: > > * The Apache HTTP Server project wants surveys of web server usage, > such as the well-known Netcraft survey, to more accurately represent > the actual use of Apache httpd. While some web server administrators > currently modify the Apache HTTP Server source code or install > third-party modules which can remove the Server header, too few > administrators do this to significantly alter the results. The same > may not be true if it is an easily-accessible feature. > > * The Apache HTTP Server project believes that most people who want to > avoid sending the Server header mistakenly think that doing so may > protect their server from attacks based on known flaws in older Apache > HTTPD releases, when in fact the only reasonable way to address these > flaws is to upgrade to new Apache HTTPD releases which correct > security problems affecting your configuration. By restricting the > ability to configure Apache in this manner, we wish to raise awareness > of the need to upgrade when critical vulnerabilities are addressed. > > (what other reasons go here?) > . > >
[Fwd: Re: vote on concept of ServerTokens Off]
Why attach email doesn't work in thunderbird is beyond me... This was Jeff's starting point for documenting ServerTokens Off. Original Message Subject: Re: vote on concept of ServerTokens Off Date: Wed, 6 Dec 2006 13:43:49 -0500 From: Jeff Trawick Reply-To: dev@httpd.apache.org To: dev@httpd.apache.org References: <200612061412.kb6ecwb10...@devsys.jagunet.com> <4576f73a.3020...@force-elite.com> On 12/6/06, Paul Querna wrote: > This thread is making me sad. No tears ;) The somewhat bright side is that pushing on this tender spot until it hurts should at the very least avoid having the same discussion here for the next couple of years, and at the most can avoid a lot of other wasteful discussions permanently ;) The middle ground of document explicitly why you can't directly turn it off should also be achievable. Proposed documentation for the ServerTokens directive. Special note: Apache HTTP Server users suggest from time to time that the ServerTokens directive allow the Server response header to be eliminated completely. This feature suggestion is rejected for the following reasons: * The Apache HTTP Server project wants surveys of web server usage, such as the well-known Netcraft survey, to more accurately represent the actual use of Apache httpd. While some web server administrators currently modify the Apache HTTP Server source code or install third-party modules which can remove the Server header, too few administrators do this to significantly alter the results. The same may not be true if it is an easily-accessible feature. * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?) .
Re: vote on concept of ServerTokens Off
Jim Jagielski wrote: > Lars Eilebrecht wrote: >> According to Jeff: >> >>> A lot of opinions were offered back in August. Some were negative but >>> I don't see anything that looks like a veto. >> I voted -1 at that time which is a veto. >> >> My opinion hasn't changed and I still think that it is a very >> stupid idea to add a "feature" that allows our users to do >> something which is stupid and absurd. >> >> *shrug* but as everyone seems to think that this is a good idea, >> feel free to ignore my veto. > > A Veto is a Veto. If you feel strongly enough about it, then > it cannot be, and should not be, ignored. Lars, yours is the last veto standing for ServerTokens Off. What say you? (Your veto would appear to imply a veto of any ServerTokens Set syntax). Bill
Re: vote on concept of ServerTokens Off
Ruediger Pluem wrote: > > On 12/05/2006 07:16 PM, Jim Jagielski wrote: >> On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: >> >>> On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: >>> A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% 3c44d03f79.2030...@nohn.net%3e) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. >>> >>> +1. Should be documented as "a bad idea" as Joshua notes in that >>> thread. >>> >> +1 (with that condition) > > +1 provided the condition above is true. Jim, when you committed ServerTokens Set, you did not address this concern expressed by a significant number of project members. http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/manual/mod/core.xml also has an error in the , it doesn't appear that you updated it. Jeff even offered a draft :) --- Begin Message --- \ ¢éí)ìqÊ.ÞQzÛ«ö ׯën®~yë®Ýzùb²Û--- End Message ---
Re: vote on concept of ServerTokens Off
-0 here.
I don't see the point of earning 20 bytes per request when you can
save many more with mod_deflate or tidying the output. It's not the
job of the webserver. I won't veto it since you might find a use to
this feature if it is implemented, but it's like you also want to let
admins personalize the server token ('Server: my sooper fischer-price
Apache webserver').
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
signature.asc
Description: Digital signature
Re: vote on concept of ServerTokens Off
Hi, what the difference with no header and Header = "Server: Apache" without version with "prod" args of servertoken... if is to hide apache version only there no need to modify ServerToken directive... if is to hide apache completly ok...it's other problem... but a security level i'm not sure they add serius difference... and for the notoriety of apache vs other web server is very importante to have statistic... beceause enterprise make disision to use opensource on the fact who are wheel known and used... and statistic is the most powerfull way to acheve this... Best Regards, Mathieu
Re: vote on concept of ServerTokens Off
On 12/6/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: ons 2006-12-06 klockan 09:38 -0500 skrev Jeff Trawick: > Why other than ego do we want to make it hard to disable this output? Technical reason: Not advertising the brand and version makes it very hard for clients (user-agents and proxies) to apply workarounds when needed. As an example Squid currently has a workaround for how Apache handles ETag in responses which has been modified by mod_deflate. In future we hope to be able to disable that for versions known to be fixed. http://issues.apache.org/bugzilla/show_bug.cgi?id=39727 Not sending the sever name and version will make this harder. Since this capability of working around issues in certain levels of Apache requires both the server name and version to be advertised, that is an argument against something you've been able to do since Apache 1.3.14 (hide the version). Colm had another argument in that category. So we could list some reasons to avoid using the existing capability to hide the server version: * make it easy to audit your web server installations for out of date versions * allow other software, such as proxy servers, to work around problems in your level of Apache
Re: vote on concept of ServerTokens Off
On 12/6/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Jim Jagielski wrote: >> >> *shrug* but as everyone seems to think that this is a good idea, >> feel free to ignore my veto. >> > > A Veto is a Veto. If you feel strongly enough about it, then > it cannot be, and should not be, ignored. /agree - I cast a -0 because I don't like it, don't think we should do it, but even more strongly feel we should stop answering the damned question "can I turn off the ..." and move on :) A moot point, but aren't a "-0" vote and the comment "even more strongly feel we should stop answering the damned question..." inconsistent? This isn't a vote for how cool we think the feature would be, but for whether or not we think it should be implemented, after weighing the different concerns.
Re: vote on concept of ServerTokens Off
On 12/6/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: On Wed, Dec 06, 2006 at 01:43:49PM -0500, Jeff Trawick wrote: > * The Apache HTTP Server project believes that most people who want to > avoid sending the Server header mistakenly think that doing so may > protect their server from attacks based on known flaws in older Apache > HTTPD releases, when in fact the only reasonable way to address these > flaws is to upgrade to new Apache HTTPD releases which correct > security problems affecting your configuration. By restricting the > ability to configure Apache in this manner, we wish to raise awareness > of the need to upgrade when critical vulnerabilities are addressed. > > (what other reasons go here?) I think the more important thing about the "security" reason, is that it actually *degrades* security, because it impedes the ability to audit. Finding out-of-date installations is an nmap one-liner if you leave the Server header alone. If you disable it, you have to start logging in to the boxes (and getting that access and so on) and check things locally. The admin who would want to code "ServerTokens Off" is already coding "ServerTokens Prod", so that is an argument to stop doing what you've been able to do since 1.3.14.
Re: vote on concept of ServerTokens Off
Jim Jagielski wrote: >> >> *shrug* but as everyone seems to think that this is a good idea, >> feel free to ignore my veto. >> > > A Veto is a Veto. If you feel strongly enough about it, then > it cannot be, and should not be, ignored. /agree - I cast a -0 because I don't like it, don't think we should do it, but even more strongly feel we should stop answering the damned question "can I turn off the ..." and move on :)
Re: vote on concept of ServerTokens Off
On Wed, Dec 06, 2006 at 01:43:49PM -0500, Jeff Trawick wrote: > * The Apache HTTP Server project believes that most people who want to > avoid sending the Server header mistakenly think that doing so may > protect their server from attacks based on known flaws in older Apache > HTTPD releases, when in fact the only reasonable way to address these > flaws is to upgrade to new Apache HTTPD releases which correct > security problems affecting your configuration. By restricting the > ability to configure Apache in this manner, we wish to raise awareness > of the need to upgrade when critical vulnerabilities are addressed. > > (what other reasons go here?) I think the more important thing about the "security" reason, is that it actually *degrades* security, because it impedes the ability to audit. Finding out-of-date installations is an nmap one-liner if you leave the Server header alone. If you disable it, you have to start logging in to the boxes (and getting that access and so on) and check things locally. I'd make that point. Personally I think we should include the functionality, I'm always in favour of allowing people to shoot themselves in the foot. Sometimes it's the only way they learn ;-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: vote on concept of ServerTokens Off
ons 2006-12-06 klockan 09:38 -0500 skrev Jeff Trawick: > Why other than ego do we want to make it hard to disable this output? Technical reason: Not advertising the brand and version makes it very hard for clients (user-agents and proxies) to apply workarounds when needed. As an example Squid currently has a workaround for how Apache handles ETag in responses which has been modified by mod_deflate. In future we hope to be able to disable that for versions known to be fixed. http://issues.apache.org/bugzilla/show_bug.cgi?id=39727 Not sending the sever name and version will make this harder. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: vote on concept of ServerTokens Off
On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: On 12/6/06, Paul Querna <[EMAIL PROTECTED]> wrote: > This thread is making me sad. No tears ;) The somewhat bright side is that pushing on this tender spot until it hurts should at the very least avoid having the same discussion here for the next couple of years, and at the most can avoid a lot of other wasteful discussions permanently ;) The middle ground of document explicitly why you can't directly turn it off should also be achievable. Proposed documentation for the ServerTokens directive. Special note: Apache HTTP Server users suggest from time to time that the ServerTokens directive allow the Server response header to be eliminated completely. This feature suggestion is rejected for the following reasons: * The Apache HTTP Server project wants surveys of web server usage, such as the well-known Netcraft survey, to more accurately represent the actual use of Apache httpd. While some web server administrators currently modify the Apache HTTP Server source code or install third-party modules which can remove the Server header, too few administrators do this to significantly alter the results. The same may not be true if it is an easily-accessible feature. * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?) Maybe that some client check the server software so they can decide the best way to talk to the server? -- ~Jorge
Re: vote on concept of ServerTokens Off
On 12/6/06, Paul Querna <[EMAIL PROTECTED]> wrote: This thread is making me sad. No tears ;) The somewhat bright side is that pushing on this tender spot until it hurts should at the very least avoid having the same discussion here for the next couple of years, and at the most can avoid a lot of other wasteful discussions permanently ;) The middle ground of document explicitly why you can't directly turn it off should also be achievable. Proposed documentation for the ServerTokens directive. Special note: Apache HTTP Server users suggest from time to time that the ServerTokens directive allow the Server response header to be eliminated completely. This feature suggestion is rejected for the following reasons: * The Apache HTTP Server project wants surveys of web server usage, such as the well-known Netcraft survey, to more accurately represent the actual use of Apache httpd. While some web server administrators currently modify the Apache HTTP Server source code or install third-party modules which can remove the Server header, too few administrators do this to significantly alter the results. The same may not be true if it is an easily-accessible feature. * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?)
Re: vote on concept of ServerTokens Off
Joshua Slive wrote: > On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: > >> We're up to two great answers to disable some output from the server >> that isn't required by the HTTP protocol anyway: >> >> 1) modify the source >> 2) install third-party module > > My support for the idea has nothing to do with improving the operation > of the server for users. I support it to make this silly issue go > away so we can move on to more interesting things. If you add up the > time spent debating this issue on this list, the users list, and the > bug database in the last 10+ years, I think it would make you a little > sad. This thread is making me sad. But I like my bikesheds in light blue: http://lightblue.bikeshed.com/ What is everyone else's favorite bikeshed colors?
Re: vote on concept of ServerTokens Off
Jeff Trawick wrote: I know... that's why I asked :) We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module ROFL. Please add to the list: 3) Start a new apache-httpd fork. "apache-phewbits" :D
Re: vote on concept of ServerTokens Off
On 12/5/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. Why do I care personally? I'd like to see an easy resolution to the common support question which doesn't involve recompiling the server*, installing third-party modules+, trying to explain that the server implementation can be easily reverse engineered anyway@, or trying to explain that attackers just send everything they have regardless of which server implementation they think it [EMAIL PROTECTED] *alas, not possible with my day job but I can solve that in a different way +not a simple task in many corporate environments @generally this seems to fall on deaf ears; I suspect that many of these people have to document exceptions to the report of some scanner every n months
Re: vote on concept of ServerTokens Off
On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module My support for the idea has nothing to do with improving the operation of the server for users. I support it to make this silly issue go away so we can move on to more interesting things. If you add up the time spent debating this issue on this list, the users list, and the bug database in the last 10+ years, I think it would make you a little sad. Joshua.
Re: vote on concept of ServerTokens Off
On Wed, Dec 06, 2006 at 03:45:54PM +0100, Lars Eilebrecht wrote: > So, is that a -1 or -0? > A peanut gallery -1. I feel very strongly about pretending to implement security measures that does not help one bit. vh Mads Toftum -- http://soulfood.dk
Re: vote on concept of ServerTokens Off
According to Mads: > On Wed, Dec 06, 2006 at 01:30:26PM +0100, Lars Eilebrecht wrote: > > I voted -1 at that time which is a veto. > > > > My opinion hasn't changed and I still think that it is a very > > stupid idea to add a "feature" that allows our users to do > > something which is stupid and absurd. > > > I agree. So, is that a -1 or -0? ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
Re: vote on concept of ServerTokens Off
On 12/6/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: > We're up to two great answers to disable some output from the server > that isn't required by the HTTP protocol anyway: > > 1) modify the source > 2) install third-party module So, uh, why do we need to make it even easier for them? -- justin Neither of those is easy in some environments. Why other than ego do we want to make it hard to disable this output?
Re: vote on concept of ServerTokens Off
Jeff Trawick wrote: > > We're up to two great answers to disable some output from the server > that isn't required by the HTTP protocol anyway: > > 1) modify the source > 2) install third-party module > Well, as you recall, I voted +1 on the patch. My concern is that others have concerns (and there is a veto on the table as well). If there were no other options for people who wished to disable the Server header, then maybe the drive would be stronger to make it part of ServerTokens. But there are other options... IIRC, being able to remove Server was a major mod_security selling point. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: vote on concept of ServerTokens Off
On 12/6/06, Lars Eilebrecht <[EMAIL PROTECTED]> wrote: According to Jeff: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. I voted -1 at that time which is a veto. oops, I didn't read all your messages --veto--- I fear that many users of Apache would actually turn off the Server header for no or for the wrong reasons (which may "harm" our market share), and therefore I'm -1 on including this patch. --veto--- That sounds like the "web server with ego" argument. Is this going to make much more difference than netcraft catching Apache hosting parked domain names one month and IIS the next? My opinion hasn't changed and I still think that it is a very stupid idea to add a "feature" that allows our users to do something which is stupid and absurd. *shrug* but as everyone seems to think that this is a good idea, feel free to ignore my veto. Retract the veto, or not.
Re: vote on concept of ServerTokens Off
On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote: We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module So, uh, why do we need to make it even easier for them? -- justin
Re: vote on concept of ServerTokens Off
On 12/6/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: Jorge Schrauwen wrote: > > On 12/6/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > > Joe Orton wrote: > > > > > > The motivation given by the submitter was that he pays per byte served, > > > it seems entirely reasonable to allow the Server header to be disabled > > > for such users. > > > > Can he install mod_security? > > > Yes, mod_security evens allows you to change it > I know... that's why I asked :) We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module
Re: vote on concept of ServerTokens Off
On 12/6/06, Joe Orton <[EMAIL PROTECTED]> wrote: The motivation given by the submitter was that he pays per byte served, it seems entirely reasonable to allow the Server header to be disabled for such users. And he has the code. If it's that important, he can change the code. (Wanna bet he doesn't use mod_deflate?) FWIW, I'm -0 on this change. I feel the same as Nick - I won't veto it, but I think it's a silly change. If people want to remove our branding, I sort of want them to go through silly hoops... -- justin
Re: vote on concept of ServerTokens Off
Jorge Schrauwen wrote: > > On 12/6/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > > Joe Orton wrote: > > > > > > The motivation given by the submitter was that he pays per byte served, > > > it seems entirely reasonable to allow the Server header to be disabled > > > for such users. > > > > Can he install mod_security? > > > Yes, mod_security evens allows you to change it > I know... that's why I asked :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: vote on concept of ServerTokens Off
On 12/6/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: Joe Orton wrote: > > On Wed, Dec 06, 2006 at 01:30:26PM +0100, Lars Eilebrecht wrote: > > According to Jeff: > > > > > A lot of opinions were offered back in August. Some were negative but > > > I don't see anything that looks like a veto. > > > > I voted -1 at that time which is a veto. > > > > My opinion hasn't changed and I still think that it is a very > > stupid idea to add a "feature" that allows our users to do > > something which is stupid and absurd. > > The motivation given by the submitter was that he pays per byte served, > it seems entirely reasonable to allow the Server header to be disabled > for such users. > Can he install mod_security? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball." Yes, mod_security evens allows you to change it -- ~Jorge
Re: vote on concept of ServerTokens Off
On Wed, Dec 06, 2006 at 01:30:26PM +0100, Lars Eilebrecht wrote: > I voted -1 at that time which is a veto. > > My opinion hasn't changed and I still think that it is a very > stupid idea to add a "feature" that allows our users to do > something which is stupid and absurd. > I agree. vh Mads Toftum -- http://soulfood.dk
Re: vote on concept of ServerTokens Off
Joe Orton wrote: > > On Wed, Dec 06, 2006 at 01:30:26PM +0100, Lars Eilebrecht wrote: > > According to Jeff: > > > > > A lot of opinions were offered back in August. Some were negative but > > > I don't see anything that looks like a veto. > > > > I voted -1 at that time which is a veto. > > > > My opinion hasn't changed and I still think that it is a very > > stupid idea to add a "feature" that allows our users to do > > something which is stupid and absurd. > > The motivation given by the submitter was that he pays per byte served, > it seems entirely reasonable to allow the Server header to be disabled > for such users. > Can he install mod_security? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: vote on concept of ServerTokens Off
On Wed, Dec 06, 2006 at 01:30:26PM +0100, Lars Eilebrecht wrote: > According to Jeff: > > > A lot of opinions were offered back in August. Some were negative but > > I don't see anything that looks like a veto. > > I voted -1 at that time which is a veto. > > My opinion hasn't changed and I still think that it is a very > stupid idea to add a "feature" that allows our users to do > something which is stupid and absurd. The motivation given by the submitter was that he pays per byte served, it seems entirely reasonable to allow the Server header to be disabled for such users. I don't see any decent technical justification for preventing this being configured, it's not as if it even required a new directive. The references to branding and affect on "apparent market share" carry no weight in technical discussion IMO. Regards, joe
Re: vote on concept of ServerTokens Off
Lars Eilebrecht wrote: > > According to Jeff: > > > A lot of opinions were offered back in August. Some were negative but > > I don't see anything that looks like a veto. > > I voted -1 at that time which is a veto. > > My opinion hasn't changed and I still think that it is a very > stupid idea to add a "feature" that allows our users to do > something which is stupid and absurd. > > *shrug* but as everyone seems to think that this is a good idea, > feel free to ignore my veto. > A Veto is a Veto. If you feel strongly enough about it, then it cannot be, and should not be, ignored. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: vote on concept of ServerTokens Off
On Wed, 6 Dec 2006 13:30:26 +0100 Lars Eilebrecht <[EMAIL PROTECTED]> wrote: > According to Jeff: > > > A lot of opinions were offered back in August. Some were negative > > but I don't see anything that looks like a veto. > > I voted -1 at that time which is a veto. > > My opinion hasn't changed and I still think that it is a very > stupid idea to add a "feature" that allows our users to do > something which is stupid and absurd. > > *shrug* but as everyone seems to think that this is a good idea, > feel free to ignore my veto. > > > ciao... -0 Just to let Lars know he's not alone, though I don't feel strongly enough about it to cast another -1. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: vote on concept of ServerTokens Off
According to Jeff: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. I voted -1 at that time which is a veto. My opinion hasn't changed and I still think that it is a very stupid idea to add a "feature" that allows our users to do something which is stupid and absurd. *shrug* but as everyone seems to think that this is a good idea, feel free to ignore my veto. ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
Re: vote on concept of ServerTokens Off
> -Ursprüngliche Nachricht- > Von: Jeff Trawick > Gesendet: Mittwoch, 6. Dezember 2006 04:17 > An: dev@httpd.apache.org > Betreff: Re: vote on concept of ServerTokens Off > > > On 12/5/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > > > > What is the latest patch that should be applied? > > I'm pretty darn sure there is no latest ServerTokens Off patch to > apply, because it needs to be reworked slightly to work with the > patch/commit you refer to below. > > > I just did a quick review of > > > > http://issues.apache.org/bugzilla/attachment.cgi?id=18775 > > > > and I think we should use the "long" version (aka > ap_get_server_description()) > > in the output of mod_status and mod_info instead the > possibly turned off version > > ap_get_server_description() > > better to review this commit: > > http://svn.apache.org/viewvc?view=rev&revision=440337 > or for 2.2.x > http://svn.apache.org/viewvc?view=rev&revision=446606 > > which does what you want. > > Maybe I was confused earlier ;) "Reviewed by: rpluem, jim" Ahm, good point. This all seemed to be so well known to me :-). I guess I need to increase my TTL for votes I gave on backports ;-). Regards Rüdiger
Re: vote on concept of ServerTokens Off
On 12/5/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote: On 12/05/2006 07:16 PM, Jim Jagielski wrote: > > On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: > >> On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: >> >>> A lot of opinions were offered back in August. Some were negative but >>> I don't see anything that looks like a veto. >>> >>> (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% >>> [EMAIL PROTECTED]) >>> >>> A concern with the logging of server version has since been resolved, >>> but implementation of the original feature died. Before Sebastian >>> Nohn's patch is revised to fit in with the subsequent changes, I'd >>> like to confirm that nobody has a strong (veto) objection to the >>> feature, and that those in favor clearly out number those against. >> >> >> +1. Should be documented as "a bad idea" as Joshua notes in that >> thread. >> > > +1 (with that condition) +1 provided the condition above is true. What is the latest patch that should be applied? I'm pretty darn sure there is no latest ServerTokens Off patch to apply, because it needs to be reworked slightly to work with the patch/commit you refer to below. I just did a quick review of http://issues.apache.org/bugzilla/attachment.cgi?id=18775 and I think we should use the "long" version (aka ap_get_server_description()) in the output of mod_status and mod_info instead the possibly turned off version ap_get_server_description() better to review this commit: http://svn.apache.org/viewvc?view=rev&revision=440337 or for 2.2.x http://svn.apache.org/viewvc?view=rev&revision=446606 which does what you want. Maybe I was confused earlier ;) "Reviewed by: rpluem, jim" Thanks...
Re: vote on concept of ServerTokens Off
On 12/05/2006 07:16 PM, Jim Jagielski wrote: > > On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: > >> On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: >> >>> A lot of opinions were offered back in August. Some were negative but >>> I don't see anything that looks like a veto. >>> >>> (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% >>> [EMAIL PROTECTED]) >>> >>> A concern with the logging of server version has since been resolved, >>> but implementation of the original feature died. Before Sebastian >>> Nohn's patch is revised to fit in with the subsequent changes, I'd >>> like to confirm that nobody has a strong (veto) objection to the >>> feature, and that those in favor clearly out number those against. >> >> >> +1. Should be documented as "a bad idea" as Joshua notes in that >> thread. >> > > +1 (with that condition) +1 provided the condition above is true. What is the latest patch that should be applied? I just did a quick review of http://issues.apache.org/bugzilla/attachment.cgi?id=18775 and I think we should use the "long" version (aka ap_get_server_description()) in the output of mod_status and mod_info instead the possibly turned off version ap_get_server_description() Regards Rüdiger
Re: vote on concept of ServerTokens Off
+1 Roy
Re: vote on concept of ServerTokens Off
On 12/5/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Jeff Trawick wrote: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. > > (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) > > A concern with the logging of server version has since been resolved, > but implementation of the original feature died. Before Sebastian > Nohn's patch is revised to fit in with the subsequent changes, I'd > like to confirm that nobody has a strong (veto) objection to the > feature, and that those in favor clearly out number those against. I recall the entire thread and two different implementations on trunk and branches/2.2 - and I'm entirely -0 on the feature, but am only -1 if it masks the information in the internal error.log. As I recall your patches split the API so that the MPM will log the 'true version' and that the patch will only affect the externally reported version. If my memory serves - then yes, let's proceed. yes, a new patch will only affect the externally reported version
Re: vote on concept of ServerTokens Off
On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% [EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. +1. Should be documented as "a bad idea" as Joshua notes in that thread. +1 (with that condition)
Re: vote on concept of ServerTokens Off
Jeff Trawick wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. +1 from me +1 Bill
Re: vote on concept of ServerTokens Off
Jeff Trawick wrote: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. > > (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL > PROTECTED]) > > A concern with the logging of server version has since been resolved, > but implementation of the original feature died. Before Sebastian > Nohn's patch is revised to fit in with the subsequent changes, I'd > like to confirm that nobody has a strong (veto) objection to the > feature, and that those in favor clearly out number those against. I recall the entire thread and two different implementations on trunk and branches/2.2 - and I'm entirely -0 on the feature, but am only -1 if it masks the information in the internal error.log. As I recall your patches split the API so that the MPM will log the 'true version' and that the patch will only affect the externally reported version. If my memory serves - then yes, let's proceed.
Re: vote on concept of ServerTokens Off
On 12/5/06, Joe Orton <[EMAIL PROTECTED]> wrote: On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. > > (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) > > A concern with the logging of server version has since been resolved, > but implementation of the original feature died. Before Sebastian > Nohn's patch is revised to fit in with the subsequent changes, I'd > like to confirm that nobody has a strong (veto) objection to the > feature, and that those in favor clearly out number those against. +1. Should be documented as "a bad idea" as Joshua notes in that thread. +1 Joshua.
Re: vote on concept of ServerTokens Off
On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: > A lot of opinions were offered back in August. Some were negative but > I don't see anything that looks like a veto. > > (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL > PROTECTED]) > > A concern with the logging of server version has since been resolved, > but implementation of the original feature died. Before Sebastian > Nohn's patch is revised to fit in with the subsequent changes, I'd > like to confirm that nobody has a strong (veto) objection to the > feature, and that those in favor clearly out number those against. +1. Should be documented as "a bad idea" as Joshua notes in that thread. Regards, joe
