[PATCH] Config: enhancing nginx default config file with added security options

[SplitIce]

expires    -1;

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.
>
> http://nginx.org/en/docs/http/ngx_http_headers_module.html
>
> 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.
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
> > 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
> yourself...
> --
> Regards,
>
> Kristian Erik Hermansen
> https://www.linkedin.com/in/kristianhermansen
> https://google.com/+KristianHermansen
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140801/ff187f45/attachment.html>