5

We have a customer who claims his site (which we host) is under HSTS, but we cannot confirm this. I told him to open that chrome page chrome://net-internals/#hsts and query for his domain, and indeed he gets a record with a dynamic_sts_observed of 1466233582 which is 2016-06-18 07:06:22 UTC. At this time actually, the customer moved to us and it's likely he had HSTS before.

I guess there is no real reason to clear that "for the web", but at least, is there a way to see when the HSTS is supposed to expire?

I can only hope it's not in the year 2021...

  • Are you asking how to view when the HSTS record stored in that particular person's installation of the Chrome browser will expire? If so, editing the question to say so explicitly might help ensure you get answers that provide what you're looking for. – D.W. Jun 24 '16 at 0:47
6

HSTS data is kept by each web browser.

When a request is made to a domain that implements HSTS, the response headers will contain a Strict-Transport-Security header that notes the maximum age of the record and optionally some other HSTS-related values.

This maximum age effectively gives a time-to-live starting at the time when the response is received.

This is illustrated, though not explicitly spelled out, by RFC 6797 section 11.2 (non-normative), which states:

The "constant value into the future" approach can be accomplished by constantly sending the same max-age value to UAs.

and

The "fixed point in time" approach can be accomplished by sending max-age values that represent the remaining time until the desired expiry time. This would require the HSTS Host to send a newly calculated max-age value in each HTTP response.

So if a domain has used HSTS in the past, then in a situation where the HSTS max-age has not been changed previously, the earliest time when no client can be expected to rely on old HSTS data is the time of the last request that returned HSTS data, plus the time that was stated in that HSTS data at that time. If the HSTS max-age has been lowered, then these time periods form sliding windows; that which ends last is the earliest time when no client can be expected to rely on old HSTS data. This is a consequence of one of the requirements in section 8.1.1 (normative):

A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache.

On any request, if the response is received over a secure transport and includes HSTS data, then as stated in section 8.1, the client UA must update its list of known HSTS hosts (normative):

If /.../ the UA MUST [either]: /.../

  • Update the UA's cached information for the Known HSTS Host if either or both of the max-age and includeSubDomains header field value tokens are conveying information different than that already maintained by the UA.

    The max-age value is essentially a "time to live" value relative to the reception time of the STS header field.

As a consequence, turning on HSTS is effectively a promise to keep offering valid HTTPS for no less than the duration of the max-age HSTS parameter, counting from the moment of the response.

As a further consequence, there is no fixed "expiration" date and time for HSTS data unless the server uses the "fixed point in time" approach described non-normatively in the RFC.

2

HSTS is set through the use of a HEADER, Namely Strict-Transport-Security: max-age=31536000 where the max-age defines how long the browser is going to remember the HSTS setting, since last time it first saw this HEADER. (atleast that is how I understand it). When the Max-Age is up the browser will redo the HSTS only if the header is again there in the request.

Common practice is to put the Max-Age at 1 year (in seconds). It is considered good practice for any TLS web page to include this header with a long Max-age, so clients know the site is supposed to be TLS and will even remember it, so MitM attacks have fewer open attack vectors.

Edit: Since the list of HTST websites is a browser specif thing, where this is set, when its set and how to find out about expiry is browser specific. and is without further details out of scope due to missing information (e.a. what broser). to list them all would be a bit long-winded and version sepcific in a lot of cases.

  • but, to get back to the concrete question, is there a way to find out when this expiration will be when such a header has already been sent and set in the past? – Adrian Föder Jun 23 '16 at 18:03
  • 1
    Nothing you said is wrong, but you didn't answer the OP. – Neil Smithline Jun 23 '16 at 18:31
0

If you're looking for the HSTS or HPKP expiration date/time for a website on a specific Chrome instance, I had the same need a few months ago and found the Pin Patrol extension to be helpful for this. (Source code is here; it's LGPL-2.1.)

(In the interest of full disclosure, I have no affiliation with the authors of Pin Patrol.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.