e.g.

Issues{Errors: []string{"First Error", "Second Error"}}

instead of

Issues{
  Errors:   []string{"First Error", "Second Error"},
  Warnings: []string{},
}

e.g. CheckDomain(), CheckResponse()

The most accurate word I can think of is "validate", but it sounds worse to me than "check".
This is not high priority, but I wanted to file a bug to remind me about it while I'm still working on v2.

Followup to #43.

For people building on top of of us who want to know what errors there were.

See the SSL Labs API for a good example.

This is definitely not needed for v2, though.

From https://crbug.com/594014

Here's the writeup of my concern:

I have a struct with two boolean values (always present) and an integer (which may or may not be present). I'm currently using an extra boolean to track if the integer is valid:

type HSTSHeader struct {
preload bool
includeSubDomains bool
maxAgePresent bool
// maxAgeSeconds is valid iff maxAgePreset == true
maxAgeSeconds uint64
}

However, I'm worried about the default integer value of 0 because it indicates an important case that should be distinguished from "not present". Specifically, I'm worried that people won't check the maxAgePresent boolean and just read maxAgeSeconds.

Alternatives:

1. Use JSON values, which have a concept of a missing key.
2. Use a pointer.
3. Make the struct into an interface, and maybe try to use a few encapsulation tricks to discourage using the struct directly (e.g. defining package-local custom type aliases that can't be used to read the values directly).
4. Use some sort of Maybe/Optional/Nullable interface for just the integer. It seems that an idiomatic way to implement this is to use a boolean and a value, but making the top-level value in the struct a special type will hopefully prevent casual misuse.
5. Use a "list" of integers that contains either zero or one value.

See https://github.com/chromium/hstspreload/blob/d537ac4e/header.go#L17 for more context.

These all feel really hacky compared to native "object" primitives in other languages. Any other options, or any reason one of my ideas is better than I think?

From https://crbug.com/593151

Right now, putting a site that sends the following header:

Strict-Transport-Security: max-age=0; includeSubdomains; preload

into https://hstspreload.appspot.com/ results in:

Sorry! Bad reply from server

We should show a helpful message.

Based on this report [1] by @fuglede on Twitter.

[1] https://twitter.com/fuglede/status/706220976112082945

Haven't gotten around to this yet.

If port 80 or port 443 redirect, they should only redirect to secure sites.

I'd just go an implement this right now, but one of our dependencies is broken on Travis right now (googleapis/google-cloud-go#246).

e.g. http.StatusInternalServerError

Since the original source, the function seems to be called on err only if err is nil.

The checkdomain() handler currently has one possible response that does not end in a newline.

Screenshot:

See the main package documentation for proper bullet point handling.

The main reason we checked the ECDSA requirement was to prevent sites from causing an non-overridable error for Windows XP users. Since Chrome is officially dropping Windows XP support in two days, we should downgrade this to a warning or drop the check entirely.

This is not a security issue, as the user input is already checked with parser.hostname, and on the server by looking for A-Z, 0-9, Hyphen, and Dot characters only.

But you should be encoding your variables, incase you start allowing UTF-8, and other characters.

With the JavaScript, use encodeURIComponent:

https://github.com/chromium/hstspreload/blob/master/hstspreload.appspot.com/page.html#L99

xhr.open("POST", "/submit/" + domain, true);

https://github.com/chromium/hstspreload/blob/master/hstspreload.appspot.com/page.html#L152

xhr.open("POST", "/clear/" + requestedDomain, true);

https://github.com/chromium/hstspreload/blob/master/hstspreload.appspot.com/page.html#L207

<a href=\"https://www.ssllabs.com/ssltest/analyze.html?d=" + requestedDomain + "\">

I'm not familiar with Go, but isn't there a way of returning JSON data without creating the string yourself? maybe with json.NewEncoder? As that should ensure the values are properly encoded.

https://github.com/chromium/hstspreload/blob/master/hstspreload.appspot.com/hstspreload.go#L136

fmt.Fprintf(w, `    { "name": "%s", "include_subdomains": true, "mode": "force-https" },`, key.StringID())

https://github.com/chromium/hstspreload/blob/master/hsts-review.go#L134

fmt.Printf("    { \"name\": %q, \"include_subdomains\": true, \"mode\": \"force-https\" },\n", result.name)

As an aside, it would be nice if this used a standard <form>, where the server responded with a HTML page without the need to use JavaScript :-)

And provide a <label> for the input, as that will help with a11y:

http://wave.webaim.org/report#/https://hstspreload.appspot.com/

The canonical URL for the current list is https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json

However, retrieving historical versions is a bit tricky. https://github.com/lgarron/hsts-preload-stats/blob/master/hsts-preload-stats.m documents past locations for the static data file.

The following has no side effects:

 issues.AddError("error")

The correct way to modify issues is to assign the new value to it:

 issues = issues.AddError("error")

During development, I have occasionally written the former. Tests should help catch changes that are accidentally introduced, but it would be nice to catch modified Issues that are never used.

It would be nice to have an "unused result" warning (similar to "unused variable") at compile or test time.

I'mma look into go vet.

In the long term, we might be able to automate removals. In the short term:

https://bugs.chromium.org/p/chromium/issues/entry?summary=Please%20remove%20[domain]%20from%20the%20HSTS%20preload%20list&labels=Hotlist-HSTS-Preload&comment=This%20is%20a%20template%20test.&[email protected]

I somehow got off on the wrong foot using tabs.

This will allow developers to test conditions locally.

hstspreload --checkHeader "preload; max-age=20"
hstspreload --checkResponse localhost:8080
hstspreload --checkDomain example.com
hstspreload --submit example.com
hstspreload --status recently-submitted.com

If we enable submission via commandline, the process should require the same explicit user consent as the website (#3). Otherwise, it would be another footgun for preload advice.

In particular, testing checkDomain against a local test server.

per lgarron a favicon was requested. Double turnstiles are used to denote tautologies (something which is true), HSTS is used to denote that https must always be used. I combined the turnstile and a padlock for this logo.

(zip has svg source and converted ico)
hstsPreloadIcon.zip

From https://crbug.com/587957

agl@ and I actually use an automated script to do what used to be the manual review for HSTS preload list submissions. The code is Google-internal at the moment [1].

Since this review is run manually at irregular intervals, this results in:

• A slower, uncertain feedback cycle on HSTS preload submissions.
• Extra work for the preload list maintainer (currently me) due to manual emails regarding rejections.

I want to run this review step automatically for hstspreload.appspot.com submissions.
AppEngine can't do this, so this requires spinning up a GCE instance and integrating hsts-review.go into the AppEngine code.

[1] https://goto.google.com/hsts-review.go

From https://crbug.com/593204

e.g.

[ ] I understand that preloading a domain through this form will require every subdomain of this site to serve a valid certificate (for that subdomain) in order to remain accessible in Chrome.

I would also like something to the effect of "I am either the owner of this site or have direct authorization form the owner of this site." but this is a silly barrier if the only real verification is the header.

Simple Levenshtein correction, e.g. Unknown token: includeDomains. Did you mean includeSubDomains?

Can also check for common tokens that are added by accident, e.g. always.

If the redirect is http://example.com to https://example.com/landing.html (rather than https://example.com/), then https://example.com/landing.html sound send a valid HSTS header with the same dynamic semantics as the preload requirements.

In particular, update should be refactored out.

c51a7c5

• valid response on port 443
• single HSTS header without the preload token

Right now, we only require that it redirects to any HTTPS page. We should make sure that the redirect immediately leads to page that will dynamically store example.com.