Websec Group,
I was reviewing the Strict Transport Security draft and I like the idea. However, one security hole that exists is one that I believe we should work to tighten. Specifically, it is the use of a 301 as specified in Section 7.2. If a UA requests initially visits a site like www.paypal.com, it would not know if the host is an HSTS host or not. Use of 301 is not secure and the user agent could be maliciously redirected to someplace other than a site owned by PayPal, for example. A possible alternative means of determining whether a given host is an HSTS host could be via WebFinger or the current RFC 6415. In parallel to issuing a query to http://www.paypal.com, the user agent could issue a query to https://www.paypal.com/.well-known/host-meta.json. Prior to acting on a response to the HTTP request, the user agent could act on the response to the WebFinger query. A WebFinger query might be: GET /.well-known/host-meta.json HTTP/1.1 Host: www.paypal.com The WebFinger response might contain something like this: { "properties" : { " strict-transport-security":"yes" } } This response returns a single response indicating the strict transport security policy. Note that since this query was issued against an HTTS server, the above might be redundant since the Strict-Transport-Security header would have been included. Even so, this might provide a standard means of checking the policy. Alternatively, one could issue a query for the specific URL requested. Let say the original request is for http://www.example.com/user/foo. Using WebFinger, one could issue: GET /.well-known/host-meta.json?resource= http %3a%2f%2fwww.example.com%2fuser%2ffoo HTTP/1.1 This more targeted request could report on the requirement to use HTTPS via a similar means, but we could also use this to facilitate a redirection. I'm not so favorable to using WebFinger as a means of redirecting a client, but if the HTTP path and HTTPS path are different, perhaps this might provide that secure replacement for 301 on HTTP. Thus, the reply might look something like this: { "subject" : "http://www.example.com/user/foo";, "properties" : { " strict-transport-security":"yes" }, "aliases" : [ "https://secure.example.com/user/foo"; ] } This would indicate (again redundantly) what that strict transport security is to be used, but would also provide an alias address that could be queried. This could effectively serve where the 301 is proposed in the current draft. As yet another possible alternative to provide an alternate means of 301 redirection, we might have this reply: { "subject" : "http://www.example.com/user/foo";, "links" : [ { "rel" : "strict-transport-security", "href" : "https://secure.example.com/user/foo"; } ] } What the above reply does is remove the "strict transport security" property, thus removing the redundancy in the previous examples. In its place, we have a single link relation called "strict-transport-security" that contains the URL to substitute for the "subject" URL. I know it's a bit late to bring this up, but I thought it is worth asking. I apologize if the 301 issue has been beaten like a dead horse, but it seemed like an open security hole as I read the draft. If I'm misreading the draft there, by all means tell me, but I do think it would be good if we close that hole somehow if it does exist. Paul
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
