On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote:
Hi, thanks for the response. Comments inline:
On Jul 29, 2012, at 10:29 PM, =JeffH
<Jeff(_dot_)Hodges(_at_)kingsmountain(_dot_)com> wrote:
-- I did not find any guidance on how to handle UAs that do not understand
this extension. I don't know if this needs to be normative, but the draft
should at least mention the possibility and implications.
Agreed. My -12 working copy now contains these new subsections..
###
10. Server Implementation and Deployment Advice
This section is non-normative.
10.1. Non-Conformant User Agent Considerations
Non-conformant UAs ignore the Strict-Transport-Security header field,
thus non-conformant user agents do not address the threats described
in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1
"Non-Conformant User Agent Implications" for further discussion.
.
.
14. Security Considerations
.
.
14.1. Non-Conformant User Agent Implications
Non-conformant UAs ignore the Strict-Transport-Security header field,
thus non-conformant user agents do not address the threats described
in Section 2.3.1 "Threats Addressed".
This means that the web application and its users wielding non-
conformant user agents will be vulnerable to both:
Passive network attacks due to web site development and deployment
bugs: For example, if the web application contains any insecure,
non-"https", references to the web application server, and if not
all of its cookies are flagged as "Secure", then its cookies will
be vulnerable to passive network sniffing, and potentially
subsequent misuse of user credentials.
Active network attacks: If an attacker is able to place a man-in-
the-middle, secure transport connection attempts will likely yield
warnings to the user, but without HSTS Policy being enforced, the
present common practice is to allow the user to "click-through"
and proceed. This renders the user and possibly the web
application open to abuse by such an attacker.
This is essentially the status-quo for all web applications and their
users in the absence of HSTS Policy.
###
That's all good text, but I'm not sure it actually captures my concern.
From the server's perspective, the fact that non-conformant UAs may exist,
the server cannot assume that UAs will honor the extension. This means that a
UA might attempt unprotected access to some resource assumed to be protected
by this extension. That is, the server can't merely select the extension and
forget about things--it still needs to to take the same care to avoid leaking
resources over unprotected connections that it would need to do if this
extension did not exist in the first place.
I think this is implied by your last sentence above, but it would be better
to say it explicitly.
Hi Ben
On this issue, it should be noted that there is never a guarantee that a UA
will respect this extension:
- Older UAs and the latest and greatest Internet Explorer do not support this
- Any UA that has not visited this website yet may try to access insecurely
- Any UA that has visited this website, but has not done so within the time
period may try to access insecurely
A server can use HSTS to reflect a "no HTTP" policy, but it cannot be used to
enforce a "only clients that know I'm STS" policy. That is outside the scope of
the draft.
A DNS-based approach could solve the TOFU issue, but older clients (or those
without access to the secure DNS) could always try to get things over HTTP
Yoav