Subject: HSTS Misuse

From: Dennis Olvany <[email-masked]>
Date: Sun, 22 May 2016 13:45:10 +0000

There is a section in the RFC that addresses DoS, but I am interested in a
particular case. Let's posit that a domain owner directs their domain to an
https server that returns an HSTS header without the domain owner's
knowledge or consent. If the domain owner then directs their domain to an
http server, the site will be unreachable from browsers that are caching
HSTS. Has there been any discussion or guidance regarding this scenario?
When is the implementation of HSTS considered to be inappropriate?

---

From: Philipp Junghannß <[email-masked]>
Date: Sun, 22 May 2016 16:03:12 +0200

Talking about hsts misuse we should not forget the so-called hsts
supercookies, which obviously makes no sense from a technical perspective
but the point that hsts can be used for tracking still stands.
What to do about that?

Unlike cookies, hsts cannot be easily purged by the user.

---

From: Dennis Olvany <[email-masked]>
Date: Sun, 22 May 2016 14:13:35 +0000

I suppose third-party HSTS may be a good way to describe the scenario I
propose. To be more clear, let's say that the https server is provided by a
web hosting company and their customer is the domain owner.
On Sun, May 22, 2016 at 10:03 AM Philipp Junghannß <[email-masked]>
wrote:

>> There is a section in the RFC that addresses DoS, but I am interested in
>> a particular case. Let's posit that a domain owner directs their domain to
>> an https server that returns an HSTS header without the domain owner's

---

From: Solarus Lumenor <[email-masked]>
Date: Mon, 23 May 2016 10:49:52 +0100

Le 2016-05-22 15:13, Dennis Olvany a écrit : 

> I suppose third-party HSTS may be a good way to describe the scenario I propose. To be more clear, let's say that the https server is provided by a web hosting company and their customer is the domain owner.

Hello. 

In my opinion its a bad practice that should be avoided.

For a domain given, a HTTPS server must only use HSTS if it serves
fully-encrypted content.
If it serves plain-text or mixed-content for a domain that uses HSTS,
it's an error. 

If you want to redirect HTTPS connexion to plain-text content then you
MUST NOT use HSTS on all the servers or CDN serving this domain.
If one or more Virtual Host activate HSTS on your domain, your clients
will be stuck for a while.

As long as HSTS in DNS is not standardized or implemented, the domain
owner does not matters, it's only a server problem. 

Solarus

---

From: Solarus Lumenor <[email-masked]>
Date: Mon, 23 May 2016 11:06:14 +0100

Le 2016-05-23 10:49, Solarus Lumenor a écrit : 

> As long as HSTS in DNS is not standardized or implemented, the domain owner does not matters, it's only a server problem.

Sorry for this anwser. 

Assuming that HSTS is activated in the DNS zone, the problem is slightly
the same.
If you activate HSTS in a zone that serve HTTP, then the connexion will
be blocked.

There is no other solution than educate users to best pratices and good
use case. 

Human problems, human solutions. :)
Solarus.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 23 May 2016 12:10:10 +0200

a DNS based HSTS is a great Idea and when used with DNSSec it gets even
better because (obvious) nobody can try and forge headers.

to address the issue of Dennis Olvan: The server (owned e.g. by some
provider) IS using HTTPS but uses HSTS without the permission of the domain
owner, which results in the scenario that he cannot use plaintext or mixed
when changing the server, or repurposing the domain. That's what I think he
means.

2016-05-2311:49 GMT+02:00 Solarus Lumenor <[email-masked]>:

> If it serves plain-text or mixed-content for a domain that uses HSTS, it’s
> an error.
>
> owner does not matters, it’s only a server problem.
>
> Solarus
>
>

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 23 May 2016 12:28:05 +0200

well but HSTS on DNS level is in my opinion a similar thing like TLSA to
HPKP and I think TLSA is a lot better because you can manage it a lot
easier and quicker.

also usually even on a provider. in many cases the owner has more control
over the DNS than the HTTP headers.

2016-05-23 12:06 GMT+02:00 Solarus Lumenor <[email-masked]>:

> If you activate HSTS in a zone that serve HTTP, then the connexion will be
> blocked.
>

---

From: Dennis Olvany <[email-masked]>
Date: Mon, 23 May 2016 10:33:12 +0000

That is precisely the caveat, Philipp. If the server is not controlled by
the domain owner then there is the possibility that an hsts implementation
could impact the domain owner's ability to repurpose the domain for non-ssl
service.
On Mon, May 23, 2016 at 6:16 AM Philipp Junghannß <[email-masked]>
wrote:

>> it’s an error.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 23 May 2016 12:37:37 +0200

also lets not forget that what will happen if we have an obnoxiouslyy long
HSTS and the domain gets sold? have fun eating that one.
obviously the issue gets even better with HPKP. for HSTS you can can get
around with letsencrypt and ANY other trusted certs but HPKP pins specific
keys, in other words when for example the previous server/owner or whoever
has pinned some EV CAs and the next owner is an individual, that person can
forget it because (for some stupid reason) individuals cant get EV certs.

2016-05-23 12:33 GMT+02:00 Dennis Olvany <[email-masked]>:

> On Mon, May 23, 2016 at 6:16 AM Philipp Junghannß <
> [email-masked]> wrote:
>

---

From: Dennis Olvany <[email-masked]>
Date: Mon, 23 May 2016 11:03:34 +0000

For lack of some prior discussion of this caveat, it would be great to hear
some opinions. While it is possible for a server provider to give the
domain owner the choice to enable hsts, I have concluded that it may be
best for a 3rd party to never implement hsts on a domain owner's behalf.
This would altogether prevent the caveat for an unwitting domain owner.
On Mon, May 23, 2016 at 6:38 AM Philipp Junghannß <[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 May 2016 16:10:50 +0300

> On 23 May 2016, at 1:37 PM, Philipp Junghannß <[email-masked]> wrote:
> 
> also lets not forget that what will happen if we have an obnoxiouslyy long HSTS and the domain gets sold? have fun eating that one.
> obviously the issue gets even better with HPKP. for HSTS you can can get around with letsencrypt and ANY other trusted certs but HPKP pins specific keys, in other words when for example the previous server/owner or whoever has pinned some EV CAs and the next owner is an individual, that person can forget it because (for some stupid reason) individuals cant get EV certs.

At least for HPKP you cannot set obnoxiously long lifetimes, as the RFC recommends limiting max-age to ~60 days.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 May 2016 16:17:09 +0300

On 23 May 2016, at 2:03 PM, Dennis Olvany <[email-masked]> wrote:

> For lack of some prior discussion of this caveat, it would be great to hear some opinions. While it is possible for a server provider to give the domain owner the choice to enable hsts, I have concluded that it may be best for a 3rd party to never implement hsts on a domain owner's behalf. This would altogether prevent the caveat for an unwitting domain owner.

Sending an HSTS header makes a statement that this domain (possibly including subdomains) is HTTPS-only for up to max-age.

If I’m the administrator for the service and I’m configuring my own server then yes, I can make this statement. 

If I’m providing the server as a service, whether I’m a CDN or just a hosting service, I would have to have a long talk with the customer to make sure they understand the benefits and implications (“If we set this header, it’s protecting you against some kinds of SSL stripping attacks, but you can’t revert to HTTP at will: you’ll have to wait for so many days”)  I don’t think this matches the way of doing business for most CDNs and hosting services, except for their very large customers.

Yoav

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 May 2016 09:44:53 -0400

On Mon, May 23, 2016 at 6:37 AM, Philipp Junghannß <[email-masked]

> HSTS and the domain gets sold?
>

A domain with a smaller bootstrap vulnerability against MITM would be more
valuable to a sensible buyer. It's 2016 afterall - worrying about how to
avoid https is needlessly swimming against the tide.

I've actually wondered about a https only TLD for the same benefit.