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

[Daniel Kahn Gillmor <[e-mail]>]

On 05/22/2013 06:52 PM, Ryan Sleevi wrote:
> 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.

It is an error for the site operator, certainly.  But for a given user,
with a browser that supports HSTS, which has received the header during
the main page load (so it is clearly not expired), and trying to fetch
content from the origin site itself (that happens to be mistakenly
linked with http:// instead of https://): in this scenario it is not a
security vulnerability for this user.

My expectation as someone who browses the web is the browser UI feeback
info is telling me things about *this connection right now*.  If i want
to get feedback about how the site is (mis)configured in ways that are
not actively harming my connection at the moment, i expect that to be
functionality provided by an extension or a web-developer-specific setting.

For example, if i'm visiting a web page that is not valid HTML, but my
browser can do a passable rendering of it, i don't expect my browser to
choke or provide a warning label that says "invalid HTML! some other
browsers might not be able to render this properly!"  (though maybe that
would be nice?)  What about sites that are using 768-bit RSA keys --
some TLS stacks might reject those too, even if this one does not;
should the browser show a warning?  What about "transvalid" certs, which
are only valid because we were able to find their intermediary CA in our
cache of previously-seen CAs?

There are lots of potential "your current connection is only safe
because of this quirky combination of your browser, the page you're
currently viewing, and your browsing history..." scenarios.  Why should
HSTS+mixed-content be singled out for special display to the user?

I would expect that site administrators don't want their visitors to see
indicators of security failure when they are using tools that are
specifically designed to be able to prevent the security failure in
question from happening.

Site administrators should *also* be happy to have a mechanism to get
reports about possible breakage on non-STS-compatible browsers, but i
don't think they would want that mechanism to be complaints from scared
users of STS-compatible browsers who actually don't have a problem.

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

Some IETF specs do mandate certain UI (e.g.
https://tools.ietf.org/html/rfc6797#section-12.1 specifies "no user
recourse"), so i hope it's not too far outside the scope of the WG to
talk about this here.

But mainly i was asking about this here because i expect folks in this
WG to have thought about these issues and to be able to explain where
they're coming from (and even be interested in working toward rough
consensus).  That already is happening, so i don't think this is a
terrible venue for the discussion :)

Regards,

	--dkg