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