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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel