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

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 5 Oct 2012 03:31:36 -0400

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

---

From: =JeffH <[email-masked]>
Date: Fri, 05 Oct 2012 11:27:20 -0700

> Specifically, it is the use of a 301 as specified in Section

Yes, this is well-understood and (prominently) noted in the security 
considerations...

###
14.6.  Bootstrap MITM Vulnerability

    The bootstrap MITM (Man-In-The-Middle) vulnerability is a
    vulnerability users and HSTS Hosts encounter in the situation where
    the user manually enters, or follows a link, to an unknown HSTS Host
    using a "http" URI rather than a "https" URI.  Because the UA uses an
    insecure channel in the initial attempt to interact with the
    specified server, such an initial interaction is vulnerable to
    various attacks (see Section 5.3 of [ForceHTTPS]).

    NOTE:  There are various features/facilities that UA implementations
           may employ in order to mitigate this vulnerability.  Please
           see Section 12 "User Agent Implementation Advice".
###

Plus, this spec is now a done deal.

However, the notion of devising some means for declaring general (web) host 
security policy and capabilities is one that's been discussed in various 
contexts (it's the question you're begging in your msg, IMV) -- and, yes, that's 
something to (now) put more cycles into thinking about.

=JeffH