- From: Philipp Junghannß <teamhydro55555@gmail.com>
- Date: Mon, 23 May 2016 12:10:10 +0200
- To: Solarus Lumenor <solarus@ultrawaves.fr>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CACHSkNq4P3SPvE+XBWBPHLb5gaWcYNS0CFz8QNP+z7BUsM_TCA@mail.gmail.com>
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 <solarus@ultrawaves.fr>: > 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 > >
Received on Monday, 23 May 2016 10:11:17 UTC