How HSTS expiration works

Question

In ASP.NET Core 2.2 application we have enabled HSTS using app.UseHsts(); which adds HSTS with max-age of 30 days in the response header.

In the fiddler

Strict-Transport-Security: max-age=2592000

Then in Chrome, if I go to chrome://net-internals/#hsts and query our domain name, I get:

Found:

static_sts_domain:  
static_upgrade_mode: UNKNOWN  
static_sts_include_subdomains:  
static_sts_observed:  
static_pkp_domain:  
static_pkp_include_subdomains:  
static_pkp_observed:  
static_spki_hashes:  
dynamic_sts_domain: subdomain.example.com //our domain name here  
dynamic_upgrade_mode: FORCE_HTTPS  
dynamic_sts_include_subdomains: false  
dynamic_sts_observed: 1572023505.777819  
dynamic_sts_expiry: 1574615505.777818  

Questions

1. What is the unit of dynamic_sts_observed and dynamic_sts_expiry. It does not look like it's in seconds. How is the value calculated?
2. If user keeps visiting site every day, does the value keep updating? In other words, is it sliding expiration?
3. What happens after expiry?
4. What happens if user has already visited the site and his browser already cached HSTS for 30 days. But in couple of days we changed the value from 30 days to 90 days. When would user's browser get the updated value? After expiry or on next visit?
5. the URL user browse is already a subdomain like https://subdomain.example.com The SSL certificate we use is wildcard certificate. *.example.com. So HSTS configuration do i need to includeSubdomain? like Strict-Transport-Security: max-age=2592000, includeSubDomain

Answer 1

1. It seconds in unix epoch time (I.e. since 1/1/1970). As Joachim’scommebt states you can view and convert that here: https://www.unixtimestamp.com/index.php

2. Yes.

3. It is as if you never saw the HSTS header (I.e. HTTPS will not be enforced).

4. After the next visit as, as per 2, it is a sliding expiration which is recalculated on each visit.

5. If the policy is at top level then you need to use includeSubDomains (note with an S as you missed that in your question), for it to affect the sub domains. You can also publish a separate policy (the same one or a different one) on each sub domain. Your top level policy is only loaded if visitors go to that site (e.g. https://example.com) so if they only go to sub domain (e.g. https://www.example.com) then the browser will not cache the top level policy. Best practice is to use includeSubDomains on all policies and to load an asset (e.g. a single pixel or maybe the company logo) from the top level domain to force that top level policy to be picked up as well so all other sub domains are protected as well. This only works if you don’t have any http-only sites (e.g. http://intranet.example.com or http://blog.example.com), in which case the best you can do is have a top level policy without includeSubDomains and then a different policy on each sub domain that does fully support HTTPS with includeSubDomains. The certificate as no bearing on HSTS (other than the fact you obviously need one for each domain protected!).