Re: [websec] Strict-Transport-Security and mixed-content warnings

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Wed, 22 May 2013 22:53 UTC

Return-Path: <ryan-ietfhasmat@sleevi.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4E611E816B for <websec@ietfa.amsl.com>; Wed, 22 May 2013 15:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeh-fhSX2ORh for <websec@ietfa.amsl.com>; Wed, 22 May 2013 15:53:41 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2511E814B for <websec@ietf.org>; Wed, 22 May 2013 15:53:34 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 5783A318059; Wed, 22 May 2013 15:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=AzdUrmfuDMWSUaFN3m/3mzGRK08=; b=Dn97b+yfx2aoPcSy7 gFtf9MHgJo7G6euJxBN0Oj/JYr0Lf5cI2Ro8TLUO3i4BDIxksmv33HEG4BJk2mCn CUSUAZzhggP7NrwZygz5KEjCe4ZFPdfhG69E/QJgNnV7W3Vbw+Vv4m742Mu2C7pF BVafOw0wGuFBGBcjJedXcheJRE=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 0C86C318064; Wed, 22 May 2013 15:53:22 -0700 (PDT)
Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 22 May 2013 15:52:52 -0700
Message-ID: <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com>
In-Reply-To: <87sj1e8yr7.fsf@alice.fifthhorseman.net>
References: <87sj1e8yr7.fsf@alice.fifthhorseman.net>
Date: Wed, 22 May 2013 15:52:52 -0700
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org
Subject: Re: [websec] Strict-Transport-Security and mixed-content warnings
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ryan-ietfhasmat@sleevi.com
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 22:53:46 -0000

On Wed, May 22, 2013 2:56 pm, Daniel Kahn Gillmor wrote:
>  hi websec folks--
>
>  I am wondering what people think the proper intersection is between a
>  web browser's mixed-content warnings and HSTS.
>
>  For example, if https://example.net has asserted
>  Strict-Transport-Security: max-age=15768000 but the homepage at
>  https://example.net/ also contains
>
>    <img src="http://example.net/example.jpg"/>
>
>  should an HSTS-compatible browser show its standard mixed-content
>  warning even though it knows to rewrite that img src to
>  https://example.net/example.jpg ?
>
>  My intuition is that this shouldn't trigger the browser's mixed-content
>  warning, but chromium 26.0.1410.43 does show it, and
>
>   https://code.google.com/p/chromium/issues/detail?id=122548#c26
>
>  suggests that palmer@ and rsleevi@ think that is the correct behavior
>  because they want:
>
> > to signal to the site author of an error - for example, if users which
> > did not have HSTS visited.
>
>  I'm not sure how the author is supposed to get this signal from the site
>  visitor's browser, though -- perhaps the expectation is that site
>  visitors will independently report the "broken lock" to the site
>  administrator?

Yes.

The view is that it's still a legitimate error for the site operator, in
that any user without HSTS protections (or with expired HSTS) is still at
risk. While HSTS may be providing protection to the user, the site itself
is still configured to serve resources insecurely, thus we still surface
it as user visible.


>
>  I also note that firefox 21.0 (when
>  security.mixed_content.block_display_content = true) doesn't show the
>  media at all, and when security.mixed_content.block_display_content =
>  false it shows the image but removes the lock from the address bar
>  (which i think is the equivalent of the "mixed content warning" these
>  days).

I believe the Firefox behaviour is an artifact of their current (partial)
implementation of mixed content blocking. According to
https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/
, future versions should distinguish between active and passive content,
and thus more closely mirror the Chromium behaviour by default (namely,
that it will block active content, but not passive content)

>
>  Do other folks have any thoughts about the right thing is to do here?
>

ISTM that UI behaviours are largely outside the realm of what the IETF
standardizes.

That said, certainly feedback is welcomed on this, and I would love to see
consistent handling (which, AFAIK, we will soon have). I'm just not sure
if this is really a "spec issue".