Bug 134505 - www.freebsd.org does not correctly process If-Modified-Since requests
Summary: www.freebsd.org does not correctly process If-Modified-Since requests
Status: Closed FIXED
Alias: None
Product: Documentation
Classification: Unclassified
Component: Documentation (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-doc (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-13 09:20 UTC by Christian Ullrich
Modified: 2009-06-24 14:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Ullrich 2009-05-13 09:20:04 UTC
(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.
Comment 1 dfilter service freebsd_committer 2009-06-21 16:45:27 UTC
simon       2009-06-21 15:45:18 UTC

  FreeBSD ports repository

  Modified files:
    ports-mgmt/portaudit Makefile 
    ports-mgmt/portaudit/files portaudit-cmd.sh portaudit.1 
                               portaudit.conf 
  Log:
  Download portaudit database from http://portaudit.FreeBSD.org/ instead
  of http://www.FreeBSD.org/ports/portaudit/.
  
  This is primarily done to work around bug in lighttpd on www.FreeBSD.org
  where If-Modified-Since isn't handled correctly possibly resulting in
  users behind web proxies getting an outdated version of the portaudit
  database.
  
  Bump portaudit version number.
  
  Big thanks to the reporter for the detailed PR with good information
  about reproducing the issue.
  
  PR:             www/134505
  Reported by:    Christian Ullrich <chris@chrullrich.net>
  Prodding by:    remko, Christian Ullrich
  
  Revision  Changes    Path
  1.25      +1 -1      ports/ports-mgmt/portaudit/Makefile
  1.15      +2 -2      ports/ports-mgmt/portaudit/files/portaudit-cmd.sh
  1.9       +3 -3      ports/ports-mgmt/portaudit/files/portaudit.1
  1.7       +2 -2      ports/ports-mgmt/portaudit/files/portaudit.conf
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 2 Remko Lodder freebsd_committer 2009-06-24 14:13:42 UTC
State Changed
From-To: open->closed

This had been fixed by Simon.