Subject: [HASMAT] strict transport security

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 19:43:13 +0800

Just sitting here in the meeting reading this document and a few things leap out.

* This document is MASSIVE.  All it does is describe a simple header, but it's surprisingly large.  It's minor, but this needs a tough edit.

* Scope: it appears that the header applies to the entire host.  It might be nice to have policies that apply to parts of a header (probably more specifically - individual resources).

* The biggest attack here - the Bootstrap MITM vulnerability - is dealt with really superficially.  The suggested mitigation - configure hosts for this - is a bit lame.

* A user might specify a policy that requires secure checking of the server policy.  I assume that you can (if you like) get this header over TLS?  If you are describing how a UA does things, how might it check - securely - whether a site has a policy.

* DNS tree walking is bad: the DNS "tree" does not correlate perfectly with administrative domains.  Is there a good reason for this to use this rather than simply relying on origin.

--Martin

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Jul 2010 21:12:43 +0200

> Just sitting here in the meeting reading this document and a few things leap out.

Thanks for the comments.

> * Scope: it appears that the header applies to the entire host.  It might be nice to have policies that apply to parts of a header (probably more specifically - individual resources).

The header needs to apply to the entire host to gain any security
benefit.  If we allow any insecure HTTP responses into the same
browser security context (i.e., the origin), then an attacker will
just entre through those responses and compromise the other resources.

If you'd like a more detailed explanation of what goes wrong when you
try to apply security policy to only part of an origin, you might be
interested in reading this paper:

http://www.adambarth.com/papers/2008/jackson-barth-b.pdf

In that paper, we present attacks on 12 browser security features that
attempted to secure "finer-grained" origins.

> * The biggest attack here - the Bootstrap MITM vulnerability - is dealt with really superficially.  The suggested mitigation - configure hosts for this - is a bit lame.

Yep.  Sadly, that seems to be the best we can do without DNSSEC.

> * A user might specify a policy that requires secure checking of the server policy.  I assume that you can (if you like) get this header over TLS?  If you are describing how a UA does things, how m…

We do indeed receive the header over TLS.  How would you ever access a
site with a self-signed certificate if you first needed to contact the
site via a valid TLS connection to retrieve the policy?

> * DNS tree walking is bad: the DNS "tree" does not correlate perfectly with administrative domains.  Is there a good reason for this to use this rather than simply relying on origin.

Yes, this is an unfortunate consequence of the way cookies work.
Suppose you wanted to protect the confidentiality of a Secure cookie
(i.e., a cookie with the Secure flag set), which, actually, is the
primary use case for the header.  Further suppose that this cookie is
a domain cookie (e.g., set for the entire example.com domain).  Now,
if the attacker causes the browser to request
https://aiodsfnuiasnis.example.com/, then:

1) We're unlikely to have the HSTS policy bit for aiodsfnuiasnis.example.com.
2) The request for https://aiodsfnuiasnis.example.com will include the
Secure cookie.

If the attacker then substitutes his certificate, the user will be
able to click through the certificate error, which lets the attacker
obtain the cookie we're trying to protect.

If we remove the "includeSubDomains" directive, that means sites can't
use HSTS to protect domain cookies.

Adam