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

Kristian Erik Hermansen kristian.hermansen at gmail.com
Thu Jul 31 19:06:59 UTC 2014


привет!

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



More information about the nginx-devel mailing list