Subject: [websec] HSTS additional directives proposal

From: steve <[email-masked]>
Date: Thu, 30 Dec 2010 04:35:18 +0700

I feel there are two issues with the current HSTS spec.  Both concern
sites with site.com -> www.site.com 301 redirects, which is quite
popular these days.  I'll just address the first concern in this
email: ensuring STS policy is set on both site.com and www.site.com
when either are visited.

Currently it seems the simplest way to do this is add a resource from
https://site.com to all of the pages on www.site.com.  This has some
potential issues and I think it should be simpler.  I'm proposing two
new STS directives: related-domains=site.com,x.site.com;
related-domains-ttl=86400.  This would instruct browsers to make https
requests to the sites listed in related-domains to check if they had
an STS policy.  They would need to store the time they requested the
site and the specified ttl.  They would skip the request for each site
if the last requested time + ttl was greater than the current date.
Once that was no longer the case they would make a new request the
next time they encountered an STS header with those directives set.
I'm not sure what the best name for related-domains-ttl would be,
maybe -interval or -max-age or something else?  Maybe
related-domains-ttl could default to some fraction of the STS policy
if not set.  There could also be a restriction to only allow
sub/parent domains in related-domains and possibly a limit on number
of domains listed in related-domains to prevent attackers from easily
polluting the STS db.

It seems to me one of the main goals here should be to make it as hard
as possible for website owners to get things wrong.  Having everything
in one place makes this is many times simpler and less error prone to
setup for websites than needing to add a resource to all their pages.
It also bypasses the performance implications if they screw up
caching/loading of the resource.

Thoughts?

- steve

---

From: Adam Barth <[email-masked]>
Date: Wed, 29 Dec 2010 21:47:47 -0800

Generally speaking, it's problematic to let one origin set policy for
another origin, even when the domains are "related" in some sense.
HSTS already has an "includeSubDomains" attribute, which is, IMHO,
somewhat pushing the envelope in this regard already.

w.r.t. your proposal below, we'd need to verify that the other domains
actually wanted to opt into HSTS and were able to establish an valid
TLS session.  That means, we'd have to open a TLS connection to those
sites and receive an HSTS header from them anyway.  At that point, you
might as well just use the Link header with rel=prefetch rather than
piling more syntax onto the HSTS header.

Adam

On Wed, Dec 29, 2010 at 1:35 PM, steve <[email-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: steve <[email-masked]>
Date: Thu, 30 Dec 2010 16:05:17 +0700

> somewhat pushing the envelope in this regard already.

To be clear I wasn't saying we should let a site set the STS policy
for any other site.  Merely to indicate to the browser that it must
make an HTTPS connection to the related domain to check if an STS
policy was set, the same way a resource would do.

> piling more syntax onto the HSTS header.

I didn't think about using the Link header.  If that work's I prefer
it (as the preferred method) to the resource method because it's
closer to having everything in one place (the headers).  But... do all
browsers support prefetch?  Is it officially still in the HTTP spec?
This site says it doesn't work with HTTPS
https://developer.mozilla.org/en/link_prefetching_faq.  Also this
would require caching headers to be set manually on wherever you
pointed the Link to as opposed to having them directly in the header.
Considering we want this as a security feature it seems like it would
be better to specify it exactly, as part of the STS header.

I agree adding syntax to the header is not great but I think in this
case it is worth it because of the simplicity it adds to setting up
HSTS.

- steve

---

From: Adam Barth <[email-masked]>
Date: Thu, 30 Dec 2010 01:26:53 -0800

On Thu, Dec 30, 2010 at 1:05 AM, steve <[email-masked]> wrote:
> browsers support prefetch?

If not, we can recommend they implement prefetch at the same time they
implement HSTS.

> Is it officially still in the HTTP spec?

I believe so, but I haven't checked.

> https://developer.mozilla.org/en/link_prefetching_faq.

That page seems to say "Starting in Gecko 1.9.1 (Firefox 3.5), HTTPS
content can be prefetched."

Given that HSTS is implemented starting in Firefox 4, I think we're ok
on that score.

> Also this

I'm not sure I understand the connection with caching.  Are you
worried that the prefetch will hit some sort of cache that lacks the
HSTS header?  That seems to only be a problem if the site isn't
sending the HSTS header consistently.

> be better to specify it exactly, as part of the STS header.

I disagree.  If a more general mechanism already does what we want, it
seems foolish to re-invent that mechanism poorly just because it
wasn't invented in this working group.

> case it is worth it because of the simplicity it adds to setting up

In the bigger picture, however, it add complexity and redundancy,
which makes it seem unnecessary.

Adam

---

From: steve <[email-masked]>
Date: Thu, 30 Dec 2010 16:42:01 +0700

> If not, we can recommend they implement prefetch at the same time they

Two issues with that.  One, I think it needs to be required, not a
recommendation.  And two, is that it makes it more probable browsers
will screw things up.  It won't be readily apparent that prefetch is
important for HSTS unless you're going to put that in the HSTS spec
(unless you're putting that directly in the spec).

> sending the HSTS header consistently.

Sorry I was't clear there.  The caching issue isn't a security concern
but a performance one.  If the site doesn't get the caching right on
whatever resource they point the prefetch header to it could impose
double HTTPS connections every time someone visits their site.

> wasn't invented in this working group.

In general I agree with that sentiment but for security purposes I'm
not sure I do.  Depending on a non security feature for HSTS seems
like a bad choice to me.  It requires every browser developer to keep
this in mind.  Maybe 3 years down the line they decide to improve
prefetch and end up breaking how STS uses it.  In terms of making HSTS
less prone to implementation screw ups it seems better to have
everything in one place.

> which makes it seem unnecessary.

If it's better/simpler security for websites that seems like a
worthwhile tradeoff.

- steve

---

From: steve <[email-masked]>
Date: Fri, 31 Dec 2010 02:02:25 +0700

Just to show how many people currently get this wrong, here's the
sites listed in the HSTS wikipedia article that screw it up.  Note
that I verified none of them are using the resource technique either
(at least correctly).

$ curl --head http://noisebridge.net
HTTP/1.1 302 Found
Date: Thu, 30 Dec 2010 18:39:21 GMT
Server: Apache
Location: https://www.noisebridge.net/

$ curl --head http://strongspace.com
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Thu, 30 Dec 2010 18:41:44 GMT
Location: https://www.strongspace.com/
Connection: Keep-Alive
Content-Length: 0

$ curl --head http://www.voipscanner.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 30 Dec 2010 18:19:31 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3
OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8
Location: https://voipscanner.com/
Content-Type: text/html; charset=iso-8859-1
$ curl --head https://voipscanner.com
HTTP/1.1 303 SEE OTHER
Date: Thu, 30 Dec 2010 18:19:25 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3
OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8
Location: https://voipscanner.com/voipscanner
Strict-Transport-Security: max-age=1800
Content-Type: text/html; charset=UTF-8

$ curl --head ssllabs.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 30 Dec 2010 18:43:56 GMT
Server: Apache
Location: https://www.ssllabs.com/
Content-Type: text/html; charset=iso-8859-1

$ curl --head http://www.squareup.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 30 Dec 2010 18:45:08 GMT
Content-Type: text/html
Content-Length: 178
Location: http://squareup.com/
$ curl --head https://squareup.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 9344
Cache-Control: private, max-age=0, must-revalidate
Strict-Transport-Security: max-age=500

- steve

---

From: Adam Barth <[email-masked]>
Date: Thu, 30 Dec 2010 11:08:48 -0800

I'm not sure what conclusions we're supposed to draw from the below.
What would you have expected them to do?

Adam

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 30 Dec 2010 12:11:29 -0700

> -----Original Message-----
> 
> Just to show how many people currently get this wrong, here's the sites
> listed in the HSTS wikipedia article that screw it up.  Note that I verified none
> of them are using the resource technique either (at least correctly).

I expect to have an adjustment in the not-too-distant future on my end, and to start cranking up the HSTS max-age in the same timeframe.  

Also, lots of sites have different amount of traffic that hits their www vs. non-www site.  Also, depending on the scope of their cookies, the type of attacks possible aren't the same.

So yes, we'd like to see things slightly differently, and will consider putting this advice into several forums:

1. Advice in the spec itself (if appropriate)
2. in the Wikipedia article.  Feel free to edit it yourself to include this general guidance if you'd like, we probably won't get to it overnight.

- Andy

---

From: steve <[email-masked]>
Date: Fri, 31 Dec 2010 02:13:13 +0700

Sorry, should have been more clear.  These are sites which fall prey
to what I talked about in my blog.  Even though they set the STS
header on their main https site many users will never be protected by
TLS if they type in the alternate site (meaning domain.com if the main
site is www.domain.com and www.domain.com if the main site is
domain.com).  The only thing I was trying to point out here was it's
not that simple to get right.

- steve

---

From: steve <[email-masked]>
Date: Fri, 31 Dec 2010 02:17:47 +0700

Yea I understand if sites do their cookies correctly then we're mainly
talking about MITM attacks here.  But again, how many people actually
get things right? :)  It would be interesting to see the ratio of who
types www. and who leaves it off.  My guess is that is something that
will change over time though.

- steve