W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: UPGRADE: Feature detection?

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 11 Feb 2015 17:05:27 -0500
To: Jacob Hoffman-Andrews <jsha@eff.org>, Mike West <mkwst@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
Cc: Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>
Message-ID: <87a90km7dk.fsf@alice.fifthhorseman.net>
On Wed 2015-02-11 15:04:21 -0500, Jacob Hoffman-Andrews wrote:
> On 02/11/2015 11:52 AM, Daniel Kahn Gillmor wrote:
>> If it's only sent during navigational requests, then the simplest
>> server-side logic will fail to redirect requests for things like
>> images or scripts that could have been redirected safely in the first
>> place.
>
> On upgrade-capable browsers, subresources with hardcoded HTTP URLs would
> be upgraded to HTTPS by the upgrade mechanism, without ever making a
> plaintext request.
>
> On non-upgrade-capable browsers, subresources with hardcoded HTTP URLs
> would first make a plaintext request. Some servers may desire to
> redirect these, but I don't think it adds any security or privacy
> benefit. The plaintext request has already hit the network and
> potentially been observed and/or hijacked.

Right, thanks for the analysis.  For hosts that use HSTS, one redirect
is still useful, but any server willing to offer HSTS wouldn't be
conditionally offering the 302 redirect, i guess.

So: how does this interact with HSTS deployment?  Any server that makes
use of this feature-detection signal from its clients is by definition
unwilling to move to HSTS, right?  What deployment tradeoffs does adding
this signal imply for website operators?  Is it a stepping-stone toward
strong HTTPS security (with HSTS) or is it a crutch for people who won't
deploy it yet?

Is it possible that a site might want to send Strict-Transport-Security
to upgrade-capable clients, but not to others?

     --dkg
Received on Thursday, 12 February 2015 13:32:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC