[websec] draft-ietf-websec-strict-transport-sec and WebFinger

["Paul E. Jones" <[e-mail]>]

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