IETF Logo Mail Archive

Re: HSTS Misuse

Solarus Lumenor <solarus@ultrawaves.fr> Mon, 23 May 2016 09:54 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 A2D5012B048 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 May 2016 02:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.346
X-Spam-Level:
X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 RB672iwIiI0Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 May 2016 02:54:36 -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 5DFAF12B020 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 23 May 2016 02:54:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1b4mVN-0004r5-01 for ietf-http-wg-dist@listhub.w3.org; Mon, 23 May 2016 09:50:33 +0000
Resent-Date: Mon, 23 May 2016 09:50:32 +0000
Resent-Message-Id: <E1b4mVN-0004r5-01@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <solarus@ultrawaves.net>) id 1b4mVG-0004pu-OM for ietf-http-wg@listhub.w3.org; Mon, 23 May 2016 09:50:26 +0000
Received: from [77.207.143.42] (helo=ultrawaves.net) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <solarus@ultrawaves.net>) id 1b4mVE-00050V-TY for ietf-http-wg@w3.org; Mon, 23 May 2016 09:50:26 +0000
To: HTTP Working Group <ietf-http-wg@w3.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_f3f11c580767600bd2b128f0edcf8fca"
Date: Mon, 23 May 2016 10:49:52 +0100
From: Solarus Lumenor <solarus@ultrawaves.fr>
In-Reply-To: <CAATNdDwUpXAvpZp-=L-mif2zDSkMjA6VtKv_hrCQZJQBmt0Ctg@mail.gmail.com>
References: <CAATNdDzB=Dgtqmyj5mB_VE24kvi9Nqt-6f2tdL0fJsZS0HypNQ@mail.gmail.com> <CACHSkNpx31zci8Kxv7LS85OJoJfuzC-hZx1RMzoiQ9-v4S=ObQ@mail.gmail.com> <CAATNdDwUpXAvpZp-=L-mif2zDSkMjA6VtKv_hrCQZJQBmt0Ctg@mail.gmail.com>
Message-ID: <7301d13860eca437fc01c21ace8d322a@ultrawaves.net>
X-Sender: solarus@ultrawaves.fr
Received-SPF: pass client-ip=77.207.143.42; envelope-from=solarus@ultrawaves.net; helo=ultrawaves.net
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1b4mVE-00050V-TY ed8a6534327432e8c7d0074c49eaa65d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HSTS Misuse
Archived-At: <http://www.w3.org/mid/7301d13860eca437fc01c21ace8d322a@ultrawaves.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31655
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>

 

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

v2.23.0 | Report a Bug | By Email