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

[Maxim Dounin]

Hello!

On Thu, Jul 31, 2014 at 12:06:59PM -0700, Kristian Erik Hermansen 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.

E.g., when talking about SSL ciphers, things tend to become stale 
in months.

> > 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.

As previously said, we are providing appropriate defaults, 
reasonably secure by default.

And, as previously said, people tend to have different ideas of 
what security is, what is secure and what is not.  And this 
discussion is an illustration of this claim.

> > 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

Please re-read the documentation and stop yourself from further 
false claims.  There is a difference between the "expires" 
directive, and the "Expires" response header line added with the 
"add_header" directive.

> 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.

When working though a proxy, clients use the CONNECT method to 
stablish opaque tunnel to a destination https server, and 
establish SSL connection via this tunnel.  The proxy server can't 
cache content transferred though the tunnel, much like any other 
attacker who is able to capture network traffic.  If a proxy is 
able to see https requests, it means that there is a successful 
MitM attack going on, and you already have zero security.  Adding 
any headers won't help - attackers won't respect headers.

Of course there may be sensitive content which shouldn't ever hit 
persistant storage, even on client's own computer.  And because of 
such cases I didn't write "in all cases".  The problem though that 
most of data isn't that sensitive even if transmitted over https.  
And disabled caching will likely do the opposite to "better 
security": people will use http instead, because https will be 
slow for them due to disabled caching.  Therefore, if a particular 
resource is really sensitive and shouldn't be cached/stored, then 
appropriate headers should be added to this particular resource, 
not to all https responses.

> 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

I'm not really sure why you are trying to refer to the RFC 2616 
without actually reading it.  Quote from RFC 2616, "14.32 Pragma",
http://tools.ietf.org/html/rfc2616#section-14.32:

      Note: because the meaning of "Pragma: no-cache as a response
      header field is not actually specified, it does not provide a
      reliable replacement for "Cache-Control: no-cache" in a response

Though RFC 2616 is obsolete now, and correct reference should be 
to RFC 7234, "5.4 Pragma", it fixes some typos in the text in 
question, http://tools.ietf.org/html/rfc7234#section-5.4:

      Note: Because the meaning of "Pragma: no-cache" in responses is
      not specified, it does not provide a reliable replacement for
      "Cache-Control: no-cache" in them.

-- 
Maxim Dounin
http://nginx.org/