Re: HSTS Misuse

Dennis Olvany <dennisolvany@gmail.com> Mon, 23 May 2016 11:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AA112D672 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 May 2016 04:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.446
X-Spam-Level:
X-Spam-Status: No, score=-8.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf7wqun1c0Y7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 May 2016 04:08:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19FA12D677 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 23 May 2016 04:08:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1b4nej-0004VH-Af for ietf-http-wg-dist@listhub.w3.org; Mon, 23 May 2016 11:04:17 +0000
Resent-Date: Mon, 23 May 2016 11:04:17 +0000
Resent-Message-Id: <E1b4nej-0004VH-Af@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <dennisolvany@gmail.com>) id 1b4nee-0004Ua-1d for ietf-http-wg@listhub.w3.org; Mon, 23 May 2016 11:04:12 +0000
Received: from mail-vk0-f45.google.com ([209.85.213.45]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <dennisolvany@gmail.com>) id 1b4nec-00086D-P2 for ietf-http-wg@w3.org; Mon, 23 May 2016 11:04:11 +0000
Received: by mail-vk0-f45.google.com with SMTP id y2so146724430vka.3 for <ietf-http-wg@w3.org>; Mon, 23 May 2016 04:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HrdkgB4o2btfxc5iLhRSdmB22p+T8NT8LO/3N9AuX1s=; b=cvYG7kTkGT+N38RkigLSr2XPT5HOZtnMqwAtoXyuRUCJ3Z3+echSxUSdG+/oJlwa7e XSr0rRLMWFGJ39YM0JQoHTQJVGeF8+TD0jEz86Cjt2KyIjNWpyXYhmeNsrmkQGKHBkOx +0Asrs+kYYcBSn+qxN1rh9v2GutYtPJWBZKBFbsb3+IVC+i8iD+76SYc13h6PDxstkcJ eU/6NsM9+RFyjubzx+JQvzx5nYEHCtwzrU2Xp2EtEltVLn2cphglECCjM/Nc+UZt3H6e BDaxysRd4TR+nrU+p808Tywd/BnAz95wpXq4TtSxTFQVQTndLODVJMs+sma5R/1/u0+C DhXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HrdkgB4o2btfxc5iLhRSdmB22p+T8NT8LO/3N9AuX1s=; b=GBXh+29/qbmQcxAZ3zhYuo1BSwVV3jQIhqRaQlJKvt1zn9f8yZQYPjR9x49jt1UV84 vgzEnnl3URtuPREaGxX4OmzG9CZhI/WZdVleim6o+4paI3BKOrFjuYiGg6zcVm7db/Tg ThG/qJI0JWe5t0u3/1THfmTrSCgvY8zGGFt4L9xB4JuUGvv4I2TKYuAxC/Y9ahiM1c8Z 5ZH4CpVvUBPbdKZ11kLObNbMc02C6MZ+A4LCrkzUfrx8b72s/7iDtceJB3qNlgoLsm9/ wup3WzhkH5RUWhJgHwDyRMWRk83d52nJixp0DRgjDbUPyT7EwSoY0NSSX/d/Z5VnTSAF OgAw==
X-Gm-Message-State: AOPr4FVSlLYRnpAIDfirWd69AvtUr5ED4rEINIVUxvgtCV3Tv0Ixu8akPnbfsFn8umZlnWtVI0rkY+vxVuifrQ==
X-Received: by 10.176.0.151 with SMTP id 23mr9249436uaj.33.1464001423608; Mon, 23 May 2016 04:03:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAATNdDzB=Dgtqmyj5mB_VE24kvi9Nqt-6f2tdL0fJsZS0HypNQ@mail.gmail.com> <CACHSkNpx31zci8Kxv7LS85OJoJfuzC-hZx1RMzoiQ9-v4S=ObQ@mail.gmail.com> <CAATNdDwUpXAvpZp-=L-mif2zDSkMjA6VtKv_hrCQZJQBmt0Ctg@mail.gmail.com> <7301d13860eca437fc01c21ace8d322a@ultrawaves.net> <CACHSkNq4P3SPvE+XBWBPHLb5gaWcYNS0CFz8QNP+z7BUsM_TCA@mail.gmail.com> <CAATNdDxmM_-MfakHa6wguM0+aOtFmEr-yFaT+-yan0PRdSJCEg@mail.gmail.com> <CACHSkNq4JpETZvB+M4bJNq7CtGfizsfaNLNABO62D_YMHbOPKQ@mail.gmail.com>
In-Reply-To: <CACHSkNq4JpETZvB+M4bJNq7CtGfizsfaNLNABO62D_YMHbOPKQ@mail.gmail.com>
From: Dennis Olvany <dennisolvany@gmail.com>
Date: Mon, 23 May 2016 11:03:34 +0000
Message-ID: <CAATNdDxy0aYvdc=KB3xgonoQOA-33zv2n1Y2U+9J7_teAye0ng@mail.gmail.com>
To: Philipp Junghannß <teamhydro55555@gmail.com>
Cc: Solarus Lumenor <solarus@ultrawaves.fr>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113f1160ce1215053380641e"
Received-SPF: pass client-ip=209.85.213.45; envelope-from=dennisolvany@gmail.com; helo=mail-vk0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-0.543, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1b4nec-00086D-P2 1b4cc99214012f4f80c29ea7698b0d6e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HSTS Misuse
Archived-At: <http://www.w3.org/mid/CAATNdDxy0aYvdc=KB3xgonoQOA-33zv2n1Y2U+9J7_teAye0ng@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31661
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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
>>>>
>>>>
>>>
>>>
>