Issues checking HSTS on .gov

[konklone]

For at least this case -- here's the curl --head result for bfelob.gov:

$ curl --head https://bfelob.gov
HTTP/1.1 302 Found
Date: Fri, 06 Feb 2015 15:30:19 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Location: https://bfelob.max.gov/
Content-Type: text/html; charset=iso-8859-1

$ curl --head https://www.bfelob.gov
HTTP/1.1 302 Found
Date: Fri, 06 Feb 2015 15:30:21 GMT
Server: Apache
Strict-Transport-Security: max-age=86400
Location: https://bfelob.max.gov/
Content-Type: text/html; charset=iso-8859-1

Both redirect to bfelob.max.gov. But I'm interested in the HSTS header for bfelob.gov. The HSTS header differs between the root and the www subdomain.

When I use site-inspector, the header it captures for HSTS is the one for www - max-age=86400. This incorrectly doesn't detect that the root is fully HSTS preload enabled.

I can dig in, but -- any ideas?

[konklone]

Perhaps related -- if not, I'll spin off a separate ticket. But site-inspector incorrectly detects applicationmanager.gov as HSTS.

Here's the curl --head for the domain:

$ curl --head https://applicationmanager.gov
HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 297
Content-Type: text/html; charset=utf-8
Location: https://login.usajobs.gov/issue/wsfed?wa=wsignin1.0&wtrealm=https%3a%2f%2fapplicationmanager.gov%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252f&wct=2015-02-06T15%3a45%3a16Z
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 06 Feb 2015 15:45:15 GMT
Set-Cookie: BIGipServerAppMan-Gov-Pool=2817529004.23296.0000; path=/

$ curl --head --insecure https://www.applicationmanager.gov
HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 297
Content-Type: text/html; charset=utf-8
Location: https://login.usajobs.gov/issue/wsfed?wa=wsignin1.0&wtrealm=https%3a%2f%2fapplicationmanager.gov%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252f&wct=2015-02-06T15%3a45%3a22Z
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 06 Feb 2015 15:45:22 GMT
Set-Cookie: BIGipServerAppMan-Gov-Pool=1928336556.23296.0000; path=/

Neither root nor www has an HSTS header. But site-inspector detects a header of Strict-Transport-Security: max-age=31536000 somehow.

[konklone]

hiv.gov is in the same position as applicationmanager.gov -- it shows a HSTS header when it doesn't have one. I have some evidence of why that might be, because aids.gov recently moved over to HSTS for everything.

[benbalter]

It looks like it's following the redirects to https://login.usajobs.gov which is HSTS. Would you expect it to return the behavior for the requested domain? The resolved domain? Here's the possibilities:

I request example.gov:

1. example.gov doesn't have HSTS
2. example.gov redirects to www.example.gov which also doesn't have HSTS
3. www.example.gov redirects to login.example.gov which does have HSTS

What would you expect it returns? Would you ever want to know about 1, 2, and 3?

[konklone]

Well, this situation isn't any of those 3, because in this case, applicationmanager.gov redirected to a different domain entirely, login.usajobs.gov. So, I expect it to be marked as a "redirect", which it is -- and I expect that to be all, I think. I would expect the HTTP headers to be those that are present on the redirect, not on the resulting domain.

For 2 -- I do expect the root and for www. to be treated as the same domain -- so if I ask for example.gov and it redirects to www.example.gov, I accept that for just about everything that site-inspector looks at, I should get back the data for www.example.gov.

For 3, where it goes to a non-www subdomain, it gets murkier, but when I think through the examples, it probably makes sense to treat that as the canonical website. That's assuming the redirect works, so that if Data.gov requested example.gov/data.json, it would redirect them to the right place.

However, HSTS is special -- it doesn't care about any of these redirects, because HSTS is in place primarily to protect users from redirects. HSTS only applies to the exact domain it's specified for -- so if:

• I ask whether HSTS is enabled for example.gov,
• and the redirect HTTP response that example.gov returns me doesn't have HSTS,
• but the www.example.gov domain I got redirected to does have HSTS...

Then example.gov doesn't have HSTS enabled. For an example of this in action at github-comment-post-time:

$ curl --head https://www.hsr.gov
HTTP/1.1 200 OK
Date: Fri, 06 Feb 2015 19:46:54 GMT
Server: Apache
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
Last-Modified: Thu, 17 Oct 2013 16:39:43 GMT
Accept-Ranges: bytes
Content-Length: 2901
X-UA-Compatible: IE=EmulateIE7
Content-Type: text/html

$ curl --head https://hsr.gov
curl: (6) Could not resolve host: hsr.gov

Right now, despite including subdomains and indicating a willingness to be preloaded, hsr.gov has failed to protect any subdomain except www and any subdomains of www. But site-inspector doesn't take this into account.

This may be an example of where site-inspector just isn't the right tool, because I think many/most other things it measures should follow redirects. HSTS is implemented as an HTTP header, which was a specific engineering tradeoff (instead of, for example, putting it in DNS or inside an x.509 certificate field or as a TLS extension), but its effect (triggering precise browser trust policy), isn't really as "stateless" or flexible as most HTTP headers are.

[konklone]

#24 and #31 have resolved this issue. HSTS is now reported on per-endpoint, and per-domain, so that users of site-inspector can draw precise, reliable conclusions about HSTS on a domain.