HSTS Preload List: State of the Union 2017

[Lucas Garron]

[sent to hsts-discuss@, cross-post to security-dev@]

Ahoy!

It’s been over 1.5 years since I sent out the first HSTS Preload “State of the Union”, and we’ve made a lot of improvements to the Chromium preloading process since then. With the help of felt@, I’ve written up our progress and woes in HSTS Preload List State of the Union 2017.

Some highlights:

• About a year ago, Google SF hosted a meetup of people working on HSTS at various browsers. Notes from the meetup are here, which include the first place where preload mechanisms for Firefox, Microsoft, Opera, and Safari were all documented.

• The Chromium preload list is is gaining ≈2000 domains per month, and has grown almost 10x since the start of 2016 (from 4000 domains to ≈38,000).

• A significant fraction of preload list entries (at least ≈20%) appear to be stale, but it is not straightforward to come up with a policy to prune the majority of old entries. The list is also growing too fast for pruning to have a big impact for Chromium right now.

• We have written documentation, open sourced our code, and automated major maintenance tasks. I’d like to give special thanks here to Martijn Croonen, an independent Chromium contributor who helped us significantly with this part!

Although the purpose of the preload list has not changed much, HSTS preloading benefits have also been in recent websec news for preloading new gTLDs and helping sites mitigate KRACK. As we contend with growth, it’s nice to see that HSTS preloading continues to be seen as valuable. :-)

In the near future, I would personally like to focus efforts on:

• Completely automating daily updates of the Chromium preload list based on additions/removals submitted to hstspreload.org

• Making sure other browsers pick up new gTLD entries for their preload list. I will start a thread about this on hsts-discuss (see below) shortly.

In the longer term it would also be nice to offer site operators predictability by getting all browsers to share the same full up-to-date list of entries, although this requires reconciling Mozilla’s pruning script with our conclusion that pruning is a low priority for Chromium at the moment. I don’t have a lot of time to invest in this in the near future, but I’m happy to advise if someone wants to take on the task of making a proposal for what to do and how to implement it.

Since more of the upcoming work would benefit from input from other browsers (and the public), I’ve created an hsts-discuss mailing list. Anyone is welcome to join if you have constructive thoughts on scaling and maintaining preloaded HSTS. :-)

Stay secure,

»Lucas