- From: Dennis Olvany <dennisolvany@gmail.com>
- Date: Mon, 23 May 2016 11:03:34 +0000
- To: Philipp Junghannß <teamhydro55555@gmail.com>
- Cc: Solarus Lumenor <solarus@ultrawaves.fr>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAATNdDxy0aYvdc=KB3xgonoQOA-33zv2n1Y2U+9J7_teAye0ng@mail.gmail.com>
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ß <teamhydro55555@gmail.com> 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. > > 2016-05-23 12:33 GMT+02:00 Dennis Olvany <dennisolvany@gmail.com>: > >> 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ß < >> teamhydro55555@gmail.com> 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 <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 11:04:12 UTC