FW: Feedback on the Strict-Transport-Security specification

Forwarding at the request of the STS-draft authors.

From: Eric Lawrence
Sent: Friday, October 09, 2009 11:42 AM
To: 'Steingruebl, Andy'; 'adam@adambarth.com'
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