Re: [websec] Notes from an HSTS Meetup (Sep. 2016)

[Eric Mill <[e-mail]>]

As a follow-up to the part of the notes about .gov, and potentially using
the HSTS preload list as a migration pathway -- that's what the .gov domain
program (an office of GSA) announced yesterday:

https://cio.gov/automatic-https-enforcement-new-
executive-branch-gov-domains/

We're using the preload list to start closing the door on plain HTTP in
.gov, for executive branch agencies to start, in a way that we feel
confident enough won't break anything.

The relevant excerpt:

This year, GSA will be taking another significant step forward in making
secure communication the default for federal web services by *automatically
enforcing HTTPS* in modern web browsers for *newly issued executive branch
.gov domains* and their subdomains.

As new executive branch domains are registered, the dotgov.gov program will
submit them to web browsers for “preloading”. After submission, it can take
up to three months before preloading takes effect in modern web browsers.
The change will be introduced to dotgov customers when they register a new
domain under the Executive Branch, and *will not affect existing or renewed
domains*.

Once preloading is in effect, browsers will strictly enforce HTTPS for
these domains and their subdomains. Users will not be able to click through
certificate warnings. Any web services on these domains will need to be
accessible over HTTPS in order to be used by modern web browsers.


We'll be finalizing the mechanics of how .gov programmatically sends
entries to the preload list with Lucas and his team over the next month.

It's a novel approach, and potentially could serve as a model for other
TLDs or suffixes -- so if folks have any feedback or suggestions about this
effort, it'd be welcome and timely.

-- Eric

On Thu, Jan 19, 2017 at 8:03 PM, Lucas Garron <[e-mail]> wrote:

> Hi all,
>
> Last September I organized HSTS meetup, and I'd like to share public notes
> of what we discussed: bit.ly/hsts-meetup-notes
> <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#>
>
> Most major browsers had at least one participant, and since I currently
> maintain the Chromium HSTS preload list <https://hstspreload.org/>, I set
> roughly half the agenda to discuss the HSTS preload list.
>
> Some highlights:
>
>    - We collectively documented the HSTS preload list processes
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#heading=h.gpm9zj53wbk5>
>    for Mozilla, Microsoft, Chrome, Opera, and Safari in one place for the
>    first time. I also also made slides documenting the Chromium preload
>    list submission process.
>    <https://docs.google.com/presentation/d/1TdSPLBqkeSGZ3mFO6bSpHaRKKwPVDzU_xVc7q5vdHrY/edit#slide=id.p>
>    - The HSTS preload list has roughly two major issues: stale/removed
>    entries, and potentially very large growth in the near future. To help
>    address this, most browsers could support out-of-band updates
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#bookmark=id.5gjn9r3a8p80>
>     if it becomes necessary. (In fact, it seems Firefox just implemented
>    this <https://twitter.com/rlbarnes/status/819640097972822020>.)
>    - Firefox has implemented HSTS priming
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#heading=h.vpdezmng8pxs>,
>    which addresses the fact that HSTS on its own does not prevent mixed
>    content. Chrome is interested in implementing this, too. :-)
>    - Related topics: history of HSTS, HSTS history leaks and
>    supercookies, how to handle demand for content filtering when HTTPS is
>    common, how to get to a place where the web can be HTTPS by default, how to
>    switch entire TLDs to HTTPS, how to prevent developers from accidentally
>    preloading.
>
> (One planned topic that we didn't end up discussing much at the meetup was
> standardizing the `preload` directive used by hstspreload.org)
>
> Based on the discussions, I am also planning to make several changes to
> https://hstspreload.org in the near future:
>
>    - Automatically handle removal requests and prune stale entries
>    <https://bugs.chromium.org/p/chromium/issues/detail?id=608599> using daily
>    scans <https://github.com/chromium/hstspreload.org/issues/35>.
>    - Once we're confident about pruning process keeps the list
>    up-to-date, get all browsers to draw from the same source of truth
>    <https://github.com/chromium/hstspreload.org/issues/76> instead of
>    filtering each other's lists. (This can reduce delays for new/removed
>    entries by several months.)
>    - Possibly raise the submission requirements
>    <https://hstspreload.org/#submission-requirements> to a minimum
>    max-age of 1 year
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#bookmark=id.s9cg5xbp1r1m>
>    .
>
> martijnc@ has also been contributing changes
> <https://bugs.chromium.org/p/chromium/issues/detail?id=595493> to
> Chromium that will make my life as maintainer easier. :-)
>
> Apologies for the delay if anyone was waiting on this. I had a lot of
> non-HSTS work to do last quarter, but I've started work on hstspreload.org
> for the bullet points above, and plan to dedicate a significant amount to
> this in early 2017.
>
> Many thanks for all the meetup participants for a productive day with
> insights about everyone's concerns and priorities. :-)
>
> Cheers,
> »Lucas
>
> On Mon, Nov 14, 2016 at 9:43 PM Emily Stark <[e-mail]> wrote:
>
>> Adding Lucas, who organized the meetup. I know he's planning to share
>> notes eventually though I don't know if they're ready for consumption
>> yet.
>>
>> On Tue, Nov 15, 2016 at 4:08 AM, John Wilander <[e-mail]>
>> wrote:
>> > Hi WebAppSec!
>> >
>> > I know there was an HSTS meetup in San Francisco on 9/30, organized by
>> > Google. Challenges with HSTS preload was one of the topics (see for
>> instance
>> > requests for removal). Could we get summary + any action points sent
>> here?
>> > Or maybe there’s already a thread on some other mailing list? Thanks!
>> >
>> > I know HSTS doesn’t fall under our working group but it relates with
>> UIR and
>> > we should follow what happens.
>> >
>> >    Regards, John
>>
>


-- 
Eric Mill
Senior Advisor on Technology
Technology Transformation Service, GSA
[e-mail], [phone] <(617)%20314-0966>