Re: fyi: Strict Transport Security specification

On Fri, Sep 18, 2009 at 10:54 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Fri, Sep 18, 2009 at 10:30 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I wonder for example if the client when receiving a
>> Strict-Transport-Security header should make a request to the root url
>> of the same origin to verify that the server indeed wants to opt in to
>> STS.
>
> That's a good idea.  Do you think we should do that for all instances
> of Strict-Transport-Security, or just for headers with the
> includeSubDomains directive?

The most conservative thing to do would be something like this:

If a request is made to a http-url where no prior STS knowledge exists:
1. Make the request as normal
(am I understanding it correctly that http requests can't opt in to STS?)

If a request is made to a http-url which has been marked as "confirmed":
1. Change the url to use a https url instead
2. Mark the request as normal

If a request is made to a http*s*-url where no prior STS knowledge exists:
1. Make the request as normal
2. If the response contains an STS header, mark the origin with the
"unconfirmed" flag.
3. If the response contains an STS header with the "includeSubDomains"
statement, mark the origin with the additional flag
"includeSubDomains"

If a request is made to a http-url where the origin of the url is
marked "unconfirmed", or where a parent origin is marked with
"includeSubDomains"
1. Make the request to the "/" resource on that origin
2. If the response contains an STS header, mark the origin as
"confirmed" and remove the "unconfirmed" flag.
3. If the response does not contain an STS header, remove any flags
for the origin. (May event want to flag it with an "opted out of STS"
or some such).
4. Follow the appropriate one of the first two rules.


This is somewhat of a simplification since you also need to take
max-age into account and such. But I hope you get the general idea.

/ Jonas

Received on Saturday, 19 September 2009 08:47:16 UTC