[PATCH] Config: enhancing nginx default config file with added security options
mat999 at gmail.com
Fri Aug 1 01:42:09 UTC 2014
Does not create an "Expires: -1" header.
It should create:
Expires: Thu, 01 Jan 1970 00:00:00 GMT
A time in the “Expires” field is computed as a sum of the current time and
time specified in the directive. If the modified parameter is used (0.7.0,
0.6.32) then time is computed as a sum of the file’s modification time and
time specified in the directive.
On Fri, Aug 1, 2014 at 5:06 AM, Kristian Erik Hermansen <
kristian.hermansen at gmail.com> wrote:
> On Thu, Jul 31, 2014 at 5:25 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > We intentionally avoid various "security recommendations" except
> > via providing appropriate defaults.
> > People tend to have different ideas of what security is, and how
> > it should be achieved. Additionally, all such recommendations
> > tend to become stale in a very short period of time.
> How do you define "very short period of time"? These are standards
> that will remain effectively indefinitely.
> > Goal of the sample configuration file is to show how to configure
> > things, not to give any recommendations.
> And I thought that it was useful to be secure by default, rather than
> insecure by default. If nginx would like to take the stance that
> security should be avoided while preferring ease of use, well OK then,
> but state that publicly here and take ownership of that stance so that
> I can reference your lack of commitment.
> > Cache-related headers are either invalid (Expires syntax doesn't
> > allow "-1" as a valid value, and "Pragma: no-cache" behaviour is
> > unspecified when used in a response) or just silly (Cache-Control
> > in question disables caching, which is irrelevant for security in
> > most cases, but will make things much slower).
> If you don't agree that "Expires '-1'" is valid, then maybe you should
> update your own internal documentation and stop recommending it, but I
> think your stance is incorrect. It is not only valid, but recommended.
> The Pragma / Cache-Control options are actually very relevant,
> especially in corporate environments. For instance, most corporations
> force outbound connections via an internal web proxy. By caching
> content served over HTTPS, an internal attacker can infer content via
> the proxy cache, which is a security issue. Sensitive content should
> not be cached, I hope we agree. And I request you consult RFC2616 if
> you think the behavior is "unspecified" as you surely aren't
> considering the same RFCs I am referencing.
> > Moreover, there is the "expires" directive to control
> > cache-related headers, and it should be used in a proper nginx
> > configuration instead, see http://nginx.org/r/expires.
> Great. Again, see my comments above regarding using it. You contradict
> Kristian Erik Hermansen
> nginx-devel mailing list
> nginx-devel at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel