Re: HSTS Misuse

[Dennis Olvany <[e-mail]>]

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ß <[e-mail]>
wrote:

> 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 <[e-mail]>:
>
> 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
>>
>>
>
>