From: Eric Lawrence
Sent: Friday, October 09, 2009 11:42 AM
To: 'Steingruebl, Andy'; '[email protected]'
Cc: Hodges, Jeff; 'Collin Jackson'
Subject: RE: Strict-Transport-Security specification
Hey, guys! You both asked me for feedback on the STS spec a while ago and I've
finally managed to dig out enough to provide some feedback.
I'm excited to see the progress here, and most of the issues I've noted are
quite minor. I am a bit concerned that the spec doesn't mandate behavior for
mixed-content; I know such requirements would be controversial and non-trivial,
but without the behavior being mandated by the spec, I think we're likely to
see divergent and incompatible behavior on STS sites.
Thanks,
Eric
Hopefully this is still the latest draft?
http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
Editorial & issues
[Section: Abstract] defines a mechanism to enabling Web sites
[Section 1: Introduction] I've never seen a spec use the word annunciate
before. Any reason not to prefer "announce" or "display"?
[Section 1: Introduction] or if a server's domain
name<http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html#domain-name>
appears incorrectly. Isn't the problem here typically that the domain name
does not appear at all?
[Section 1 : Introduction] a HTTP request header field is used to convey site
policy to the UA. This specification proposes a HTTP response header, not a
request header.
[Section 2.2: Policy Summary] terminates, without user recourse, any secure
transport connection attempts upon any and all errors. I'm not convinced that
any and all is the right way to go here. Shouldn't this spec call out each
certificate and certificate chain error? Otherwise, should I consider the
failure in a different protocol level (e.g. gateway or DNS hiccup) as a fatal
error?
[Section 2.4.2: Detailed Core Requirements]: 4.UAs need to re-write all
insecure UA "http" URI loads to use the "https" secure scheme for those web
sites for which secure policy is enabled. This requirement is insufficiently
specific and does not really explain what "rewrite" means? Does this mean that
the HTML parser will detect any insecure-but-should-be URIs and rewrite them
within the markup, such that JavaScript could observe the change in the HREF
attribute? Or does it simply mean that upon de-reference the URI is
automatically "upgraded" to HTTPS with no notice to the caller?
[Section 2.4.2: Detailed Core Requirements]: Requirements #5 and #6 are
problematic because browsers (generally speaking) often don't have rock solid
knowledge of where the proper "private domain" / "public suffix"
transition<http://blogs.msdn.com/ieinternals/archive/2009/09/19/Private-Domain-Names-and-Public-Suffixes-in-Internet-Explorer.aspx>
occurs.
[Section 4: Terminology] The production of the "Effective Request URI" omits
the protocol scheme. I assume this was inadvertent and that the protocol
scheme was meant to be included.
[Section 5.1: Syntax] The spec should probably specify whether the
"delta-seconds" value expected to be adjusted by the HTTP "Age" response
header, if present.
[Section 5.1: Syntax] Are the tokens intended to be interpreted
case-sensitively?
[Section 5.1: Syntax] What should be done if the server has multiple
Strict-Transport-Security response header fields of different values?
[Section 5.1 Syntax] Typo: Strict-Transport-Sec HTTP Response Header
[Section 6.1: HTTP-over-Secure-Transport Request Type] Why must the server
include this header on every response? This seems likely to prove
prohibitively difficult across, say, Akamai load balancers for images, etc.
What happens if the server fails to include the response header on a given
response?
[Section 6.2] I'm not sure why the spec contains the confusing terminology
"HTTP-over-Secure-Transport" whilst simultaneously demanding that various URLs
be converted to specifically "HTTPS", which would preclude the flexibility
allowed by the more awkward terminology?
[Section 6.2] A STS Server must not include the Strict-Transport-Security HTTP
Response Header in HTTP responses conveyed over a non-secure transport. Why
not? It seems harmless to include if the UA doesn't respect it.
[Section 7.1] What if the STS response header is present but contains no
tokens? 7.1 suggests that the header alone indicates an STS server.
[Section 7.1.1; Design Decision #4] I know there are reasons to avoid using
secure protocols to IP-literal addressed servers, but in Intranet environments
this may be expected and desirable. Why forbid it here?
[Section 7.1.2] While I understand the restrictions imposed here, it is
something of a shortfall that https://www.example.com cannot enforce STS for
requests to http://example.com. The threat here is obvious: the user typically
visits https://www.paypal.com and gets STS applied, but in a coffee shop or
untrusted network, inadvertently types just "paypal.com" in the address bar.
Because STS isn't applied cached for that server, possible exploit occurs.
[Section 7.3] If there are any certificate errors in a HTTPS request, you
better not have gotten any HTTP "header fields" back from the server; if you
did, you've implemented HTTPS incorrectly.
[Section 9] expiry time match that for the web site's domain certificate I'm
not sure I understand the intent of synchronizing such expiration? Wouldn't
you explicitly not want to synchronize expiration of STS and the certificate,
such that the expired certificate is properly no longer useful when it expires?
[Section 10: UA Implementation Advice; Section 2.4.3: Ancillary Requirements;]
This portion of the spec troubles me the most. I was looking forward to this
spec settling things once and for all and requiring mixed content to be treated
as a fatal error. However, the spec doesn't require that, and thus I think it's
missing out on an absolutely critical opportunity. If UAs differ in behavior
(e.g. IEvN silently blocks "without recourse" mixed content but Firefox does
not) then it's likely that users and developers will erroneously conclude that
the more secure UA is "broken" or
"buggy."<http://blogs.msdn.com/ieinternals/archive/2009/06/22/HTTPS-Mixed-Content-in-IE8.aspx>
Having noted this, I do need to observe that controlling mixed content is
harder for IE than for any other browsers, because IE requires add-ons to go
directly to the network stack (WinINET/URLMon) while competitive browsers
typically expect that the add-on will use NPAPIs to request that the host
browser collect data on their behalf.
Other cases of "mixed" content: the WebSocket specification, which supports
both secure and insecure modes. Ditto for FTP/FTPS.
[Section 10] I was disappointed not to see any mention of the privacy
implications of STS hostname storage, and/or recommendations on how such
storage should interact with browser "private modes" and/or cleanup features.
[Section 10] I was happy to see the section on vendor-configured/default STS
policy. I think this is a promising mechanism.
[Section 11.1] I think the discussion of DoS bears further explanation, on the
grounds that it doesn't describe what a "fake STS header" is and how it can be
set. More specifically, it doesn't mention the aspects of the preceding spec
that make this attack difficult to execute.
[Section 11.3] The NTP attack is very cool.
Other thoughts: Should STS offer a flag such that all cookies received from the
STS server would be automatically upgraded to "SECURE" cookies?
One threat not mentioned is cross-component interactions. This spec appears to
primarily concern browsers, while the real-world environment is significantly
more complex. For instance, there are a number of file types which will
automatically open in applications other than the browser when installed; those
other applications may perform network requests to an STS host using a network
stack other than that provided by the browser. That network stack may not
support STS, or may not have previously cached STS entries for target servers.
Thus a threat exists that out-of-browser requests could be induced that
circumvent STS.
-Eric
