Feedback on the Strict-Transport-Security specification (EricLaw)

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

Received on Tuesday, 8 December 2009 21:33:35 UTC