Bug 134505

(While this issue has security implications, it does not do so _directly_, so I think that a public bug report is OK. I'm calling it a "serious" bug anyway.)

The HTTP server at www.freebsd.org fails to correctly process requests with the If-Modified-Since header (for HTTP/1.0, see RFC 1945, section 10.9). This affects, among other things, downloads of the portaudit vulnerability index file at <http://www.freebsd.org/ports/auditfile.tbz>.

When portaudit accesses this file directly, it does not send an If-Modified-Since header, but if there is a cache in the way, the portaudit run that is part of the daily security cron job will fail.

Sample HTTP dialog (some headers removed):

> GET /ports/auditfile.tbz HTTP/1.0
> If-Modified-Since: Wed, 06 May 2009 10:10:07 GMT
> Host: www.freebsd.org
> User-Agent: fetch libfetch/2.0
> Via: 1.1 my.squid.local
> Cache-Control: max-age=0
> Connection: keep-alive

< HTTP/1.0 304 Not Modified
< Connection: keep-alive
< Content-Type: application/x-bzip-compressed-tar
< Accept-Ranges: bytes
< ETag: "1975729766"
< Last-Modified: Wed, 13 May 2009 07:10:04 GMT
< Date: Wed, 13 May 2009 07:33:00 GMT
< Server: httpd/1.4.x LaHonda

The 304 response leads to squid delivering its cached copy of the file.

squid does not verify that the Last-Modified date the server provided is in fact less than or equal to the If-Modified-Since date squid sent, nor does it compare the ETag to that of the cached copy.

In some experimental requests, I have come to the conclusion that the inclusion of an If-Modified-Since request header containing _any_ valid "rfc1123-date" (using the term from RFC 1945) will result in a 304 response. If the header values does not match this syntax, or if the date is invalid in a blatant way, a 200 response is sent.

How-To-Repeat: curl --header "If-Modified-Since: Thu, 1 Jan 1970 00:00:00 GMT" -I http://www.freebsd.org/ports/auditfile.tbz

Note the 304 response.