Subject: [websec] Decouple HSTS's two orthogonal effects?

From: Matt McCutchen <[email-masked]>
Date: Wed, 23 Mar 2011 23:46:36 -0400

HSTS as currently specified has two effects on browser behavior:

1. Redirecting all requests to https
2. Preventing the user from accepting bad certificates

These are completely orthogonal; it's just that webmasters who like
transport security often want both.  There are some use cases for having
one effect without the other:

1 without 2: Prevent cookie forcing
(http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcing.html)
without breaking users who choose to disable all the default CAs and
accept server certificates individually.  These are the considerations I
would apply to my personal web site.

2 without 1: Keep https requests secure while some requests continue to
go unencrypted for performance.  (An alternative is to move the
unencrypted resources to a subdomain.)

I don't find either of these cases extremely compelling, but it may be
worth decoupling the two effects in accordance with general design
principles.

-- 
Matt

---

From: Tom Ritter <[email-masked]>
Date: Thu, 24 Mar 2011 00:22:31 -0400

I'm new to this list, so apologies if this has been discussed - but I
was surprised and dismayed when I learned of the coupling of these two
effects.  A very common situation I find myself in is adding an
exception for a self-signed certificate or otherwise untrusted
certificate, either for a personal machine, development machines, or
intranet machines.  The individual cert is verified by fingerprint
using out-of-band channels, added, and doesn't change for a while -
and we'd like to use HSTS on these boxes.  But based off my simple
testing in Chrome - coupling these effects prevents this workflow.

-tom

---

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 23 Mar 2011 22:18:12 -0700

What design principle is this ?

Seems to me that a design principle should be `don't mix orthogonal
design goals'. If a single goal has multiple effects, so be it. The
design goal is ensuring that interaction with website is not
vulnerable to MITM attacks. Since users click through cert warnings,
showing warnings is not enough (hence the effect 2). And because of
the way the web platform is designed, just switching half-way to SSL
doesn't really buy much security, hence effect 1. But the design goal
is just 1.

If the use cases you mentioned are compelling, then they should be
handled via a separate mechanism. I personally don't find them too
compelling. For Tom's intranet example, (or imagine a large
enterprise), the right thing might be to just add the cert issuer to
the browser CA store.

=devdatta

On 23 March 2011 21:22, Tom Ritter <[email-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 24 Mar 2011 19:30:48 +0000

Hello Matt and Tom,

I also do not share your view. HSTS has one goal and that is to ensure a
secure and trusted connection to prevent MiM and spoofing attacks. For
this a strict behavior must be enforced. That means only https
connections are allowed and self-signed certificates must be rejected.
Otherwise an attacker uses exactly this to bypass the protection.

Considering Tom's scenarios of self-signed certificates for intranet-site:
- As devdatta writes you should in that case deploy the certs  to your
browser.
- And second, in the long-run there might also be the additional use of
stored certs in DNSSEC (see dane WG, "DNS-based Authentication of Named
Entities"), though I admit that this is still a longer way to go.

BR, Tobias