Subject: products in Server header field

From: Nicolas Krebs <[email-masked]>
Date: Fri, 2 Mar 2007 00:21:22 +0100

I wish to know which data are allowed in Server: header-field (HTTP 1.1). 
May i put in an HTTP response "Server: Apache Plone Zope Python" ?
Does "the software used by the origin server to handle the request" include or 
allow each software involved in the answer ? 

References: 
* RFC 2616 section 3.8 Product Tokens
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8
* RFC 2616 section 14.38 Server
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.38

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 02 Mar 2007 04:59:19 +0100

> May i put in an HTTP response "Server: Apache Plone Zope Python" ?

Yes, if you like to. But you should try make sure to use the official
names for each product, possibly with a /version component.

> allow each software involved in the answer ? 

You may add tokens for any software component you consider may be
significantly relevant for how the request was processed and the answer
was generated.

The main reason for publishing software details like this is allow the
server software to be identified making it easier to diagnose problems.

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Thu, 1 Mar 2007 21:02:03 -0800 (PST)

It is worth noting that it is sometimes not advisable to provide details
in the Server: field. Crackers are known to use this information to
identify vulnerabilities unique to the http server or host OS based
on version information.

---

From: "Justin Erenkrantz" <[email-masked]>
Date: Tue, 6 Mar 2007 13:33:11 -0800

> identify vulnerabilities unique to the http server or host OS based

What we tend to see is that they just try all exploits irregardless of
what is reported by the server.  Now, someone who specifically wants
to target your box may use that info to get more information - but
there are generally easier ways to fingerprint OSes (via TCP/IP
sequence numbers, etc.) that you can't really control for either.
Just another lesson that security by obscurity is bad.  -- justin