I'm interested in HSTS mechanism and want to clarify following moment:
For example, there is site https://example.com exists. I use chrome://net-internals/#hsts to check if HSTS enabled there. And it shows the next information:
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: example.com
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: true
dynamic_sts_observed: 1524145911.957196
dynamic_sts_expiry: 1555681911.957194
dynamic_pkp_domain:
dynamic_pkp_include_subdomains:
dynamic_pkp_observed:
dynamic_pkp_expiry:
dynamic_spki_hashes:
So I expect and think that HSTS is enabled there. But at the same moment there is no Strict-Transport-Security header in response. Why does chrome show such information and is HSTS enabled for that site?
But at the same moment there is no Strict-Transport-Security header in response.
It must have been there at some point because the dynamic entry has been added to your instance of Chrome.
Also remember that HSTS can be sent on any resource, not just the main document. So if you have it being sent on a logo resource, then that will set it for the whole domain.
You could clear it using the same chrome://net-internals/#hsts page and see if it comes back after browsing around? If so then something is still sending it, if not then maybe the site used to advertise HSTS but no longer does.
It was set to be active for one year:
(1555681911.957194 - 1524145911.957196) / 365 / 24 / 60 = 1 year
And from my rough calculations trying to convert those date stamps, it looks like it was last set on 20th April 2018.
If the site has indeed stopped using HSTS, for whatever reason, it might be better to advertise a 0 header instead so at least those visitors that visit over HTTPS now will remove the policy:
Strict-Transport-Security: max-age=0; includeSubDomains
Anyone who doesn't visit over HTTPS will not get this cleared until it expires.
HSTS represents HTTP Strict Transport Security. At the point when you have HSTS support it doesn't permit the site to be initially stacked in HTTP before utilizing the 301 redirects. This implies there is no time for any programmers to slip in and use it with HTTP and keep the site from stacking HTTPS. HSTS permits the site to stack just in HTTPS giving an additional layer of security for your site. This security layer tells the program that the site has HTTPS assurance and there is no compelling reason to attempt to access the site in HTTP. This will close the little window that the programmers got during the 301 redirects.
See Steps below:
To know detailed understanding of hypertext protocols and HSTS support click here.
Related
In MDN HTTP Strict Transport Security (HSTS), it has an example of HSTS settings as below
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
where I can find the corresponding mean of max-age and includeSubDomains in RFC 6979, but it does not have the meaning of preload.
I have tested in latest Chrome and Firefox, and it seems that preload does not do anything at all. With and without preload, on requesting http request, both trials if using Chrome, can find 307 Internal Redirect made by Chrome browser without requesting to the server, which is what HSTS expect.
So what is the purpose of preload?
In addition, even if I add HSTS header, it will still have a chance to be attacked, on the first time the user visit the website with HTTP. How can we mitigate from this risk? That is, how can we tell the browser to add the domain to HSTS list before any request are sent to the server?
P.S.
I have found https://hstspreload.org/, which if I need to register the domain, requires me to add max-age and preload directive. Is it the reason why preload is necessary? And this should be the page where I should add my domain to ensure new user are safe from SSL Stripping Attack?
Preload is a big commitment. It will effectively be hardcoded into a browser’s code. Given it takes several months at a minimum to roll out new version, it’s basically irreversible.
Also as it’s down at the domain level, mistakes have been made. For example preloading domain.com but covering that blog.domain.com, or intranet.domain.com have not been upgraded to HTTPS. At this point your options are 1) upgrade side to HTTPS and live with zero users to the site until the or 2) reverse the preload and wait the months for that to roll out to all browsers and deal with zero users until then.
HTTPS is much more common now, so the risks are reduced but when HSTS preload first came out, these were real risks.
Therefore the preload attribute was a signal that the site owner was ready for that commitment. It also prevent someone else submitting a site that wasn’t using this header (whether maliciously or with good, but misguided, intentions).
You are correct in that it doesn’t “do” anything in the browser.
There was also talk of checking if the preload header was still being sent, and if not removing the preload but not sure if that’s done.
I recently started serving the 'strict-transport-security' header on one of my websites. A problem I hadn't anticipated is that my SSL certificate only covers mydomain.com and so if a user visits www.mydomain.com, rather than being redirected (as would previously happen), they are seeing a security error presented by their browser due to the fact that the new header is disallowing all non-https communication.
For various reasons I'm using a multi-domain certificate so cannot simply buy a new cert with 'www' added to it.
I understand why this is expected behaviour however I'm wondering if there is anyway for me to redirect www to non-www despite www not having a valid certificate on the www domain?
If it makes any difference, my server is running Ubuntu.
As mentioned in the comments if you have includeSubDomains in your HSTS header then this will cause you problems as browsers who have this header will try to visit https://my.yourdomain.com (i.e. over HTTPS) which will give a cert error.
To be honest best practice is to include both mydomain.com and www.domain.com if any certificates and most CAs will include these two domains for the same price. This does not work for multi domain or wildcard certificates, but is still best practice so should be done where at all possible.
You could of course drop the includeSubDomains part of your HSTS header, as suggested in the comments, and this will solve the issue (once any cache responses as given by maxage time - which looks to be one year from your example) however there are other risks here. For example someone could set up wwww.mydomain.com (with 4 w's) or secure.mydomain.com or any other legitimate looking subdomain and serve it over http instead of https and visitors might not notice. Additionally subdomains may get access to, or be able to set, cookies for domains they are part of using the path attribute. These are edge cases and having HSTS even without includeSubDomains is still offering massive protection so still it's better to include this even without includeSubDomains, but if going to the effort of turning on HSTS then it would be better to be able to turn it on fully.
Anyway at the end of the day, no matter what the risks are, it's still advised to both 1) serve the www subdomains over HTTPS as some people or pieces of software will try this domain and avoids any issues - whether using HSTS or not, and 2) use HSTS, ideally with includeSubDomains where possible.
I know nothing about this stuff so please ELI5 in your replies.
Following the instructions from my provider, Dreamhost, I installed an SSL certificate and then added these lines to my .htaccess file to force HTTP requests to be rewritten to HTTPS requests.
# Redirect http requests to https
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Everything seems to be working correctly, ie: every time I try to access a page under that domain with HTTP, it is rewritten to HTTPS and the "Secure" icon shows in the address bar.
My question is, do I need to also enable HSTS? Reading about it, it seems to do the exact same thing as the previous changes to the .htaccess file. Here's an excerpt from A2 Hosting (not my provider):
Enabling HSTS
When HSTS is enabled for a site, web browsers automatically change any
insecure requests (http://) to secure requests (https://). All you
need to do to enable HSTS is add a header to your site's .htaccess
file. Web browsers recognize this header, and then take care of the
rest without any further intervention on your part.
They suggest adding this to .htaccess:
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Another tutorial, this time specific to Dreamhost, says to enable HSTS along with forcing HTTPS in the .htaccess file, but doesn't really say why. This page suggests something slightly different:
Header set Strict-Transport-Security "max-age=31415926; includeSubDomains; preload" env=HTTPS
Do I need the "https rewrite" code snippet AND HSTS? Or is having only the "https rewrite" code snippet good enough? Do I need the HSTS code at all, and if so, what's the difference between the two lines of HSTS code in my post?
HSTS lets the browser know to only connect over https by default but each one of the different flags does something a bit different:
includeSubdomains
That means that if your site is on mydomain.com, the policy will apply to all subdomains (i.e. foo.mydomain.com, bar.mydomain.com, etc). Without this included. the policy only applies for the exact domain in question.
preload
While HSTS is great conceptually, the first time someone types mydomain.com the browser will try to contact your site on http scheme since it doesn't know that you have your site on https which gives a MITM attacker room to serve you malicious version of the site (aka TOFU problem).
To work around this, there is a centralized list for browsers for sites that should be contacted on https by default but to be able to get yourself on that list, you have to have the preload flag in that header. You can see more about this here.
The default, if a scheme (http or https) is not explicitly specified, is http.
Therefore a redirect is necessary to redirect it to your preferred https version since most visitors who type the URL will not include the scheme and so go to http version.
HTTP Strict-Transport-Security (HSTS) is a security method, to ensure you always stay on https. It is not really intended to do away with the need for the redirect. In particular HSTS works by sending your web browser a message (using a HTTP response header) to say "please only use https for this site, for the next X amount of time". This message should only be sent when visiting the site over https. Therefore if you do not redirect in the first place, then a lot of visitors may not even realise you have a https site and so will not get the HSTS instruction.
HSTS is mostly used as a way to change the default of a website to https, and to prevent man in the middle (MITM) attacks which might attempt to keep you on http: e.g. if you connect to a hacker's wifi network and go to your bank website, they will not be able to hijack this connection if it's done over https but will be able to if it's done over http, so attackers will intercept the http request and stop the redirect happening, to keep you on http and intercept all messages to and from your bank.
You can "preload" the HSTS instruction in web browser's code, which gives even more security, as you don't need to visit the site over https first to get the HSTS instruction. This should be caveated that there is basically no way back from this and this should only be considered if you really understand HSTS. There are many, many, many requests to remove sites from Preload list which takes a minimum of 3 months for Chrome (no guarantees for other browsers) and makes your site completely inaccessible during that time if you are not on https. So there is a real danger here! Particularly if some of your site is served over https (e.g. www.example.com) but some of it is not (e.g. intranet.example.com). This is a danger of HSTS as well but even more dangerous with preloading.
The other point to note is that many web agents will not use HSTS and especially not preload lists (e.g. Search Engine Crawlers, older browsers... etc). So again HSTS should be used on top of, instead of as a replacement to, a redirect.
HSTS is a great security measure and should be used by all sites (once they have stopped using http completely) but, like most security measures, does come with its own risks. So make sure you understand it before deploying it. I hate sites and tutorials that say turn it on without explaining it and the risks. In theory a site using HSTS may no longer need to redirect, but in practice it still will need to for the first visit and agents that don't understand or implement HSTS.
To summarise:
Always use redirects.
Strongly consider HSTS, but read up on it first, and start with a low max-age, and without includesubdomains and preload - until you truly understand what they mean.
if running a high risk site, then consider submitting your site to HSTS preload list as a high level of security, but again be aware of risks here. Only do this if you really understand HSTS and feel like you need this level of security.
When reading the spec for HSTS (Strict-Transport-Security), I see an injunction in section 7.2 against sending the header when accessed over http instead of https:
An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport.
Why is this? What are the risks if this is violated?
The danger is to the availability of the website itself. If the website is able to respond (either now or in the future) over HTTP but not over HTTPS, it will semi-permanently prevent browsers from accessing the site:
Browser: "I want http://example.com"
ExampleCom: "You should go to the https:// URL now and for the next 3 months!"
Browser: "I want https://example.com"
ExampleCom: [nothing]
By only serving the STS header over HTTPS connections, the site guarantees that at least right now it is not pointing browsers to an inaccessible site. Of course, if the max-age is set to 3 months and the HTTPS site breaks tomorrow, the effect is the same. This is merely an incremental protection.
If your server cannot positively tell from request characteristics whether it is being accessed over HTTP vs. HTTPS, but you believe you have set up your website to only be accessible over HTTPS anyhow (e.g. due to SSL/TLS termination in an nginx proxy), it should be safe to serve the header all the time. But if you want to serve both, e.g. if you wish to serve HTTP->HTTPS redirects from your server, find out how your proxy tells you about the connection and start gating the STS header response on that.
(Thanks to Deirdre Connolly for this explanation!)
Not sure if you have a specific issue you are trying to solve, or are only asking for curiosity sake but this might be better asked on http://security.stackexchange.com
Like you I can't see the threat from the server sending this over HTTP. It doesn't really make sense, but I'm not sure if there is a risk to be honest. Except to say if you can't set up the header properly then perhaps you're not ready to implement HSTS as it can be dangerous if misconfigured!
The far bigger danger is if a browser was to process a HSTS header received over HTTP, which section 8.1 explicitly states it MUST ignore:
If an HTTP response is received over insecure transport, the UA MUST
ignore any present STS header field(s).
The risk here is that a malicious attacker (or an accidentally misconfigured header) could take a HTTP-only website offline (or the HTTP-only parts of a mixed site) if a browser incorrectly processed it. This would effectively cause a DoS for that user(s) until either the header expiries or the site implements HTTPS.
Additionally if a browser did accept this header over HTTP rather than HTTPS, it could be possible for a MITM attacker to expire the header by setting it to a max-age of 0. For example if you have a long HSTS header set on https://www.example.com but attacker was able to publish a max-age=0 header with includeSubDomain over http://example.com, and the browser incorrectly processed that, then it could effectively remove the protection HTTPS gives to your www site.
For these reasons it's very important that clients (i.e. webbrowsers) implement this correctly and ignore the HSTS header if served over HTTP and only process it over HTTPS. This could be another reason the RFC states servers must not send this over HTTP - just in case a browser implements this wrong but, to be honest, if that happens then that browser is putting all HTTP only websites at risk as a MITM attacker could add it as per above.
This seems like a silly question but I am wondering:
How is HSTS deployed without forcibly redirecting users to HTTPS?
How is HTTP content still served from the same domain as one using HSTS? (Either an entire site or mixed content)
Why would anyone do this?
I'm reading from the EFF site and it appears that that was done:
We recently enabled HSTS for eff.org. It took less than an hour to set up, and we found a way to do it without forcibly redirecting users to HTTPS, so we can state an unequivocal preference for HTTPS access while still making the site available in HTTP. It worked like a charm and a significant fraction of our users are now automatically accessing our site in HTTPS, perhaps without even knowing it.
As I'm aware, HSTS works by sending an HTTP header:
Strict-Transport-Security: max-age=31536000
So if I access a page on https://example.net/ that sends that header, all future requests to the domain example.net for the next 31536000 seconds will use HTTPS, and if the (response?) is HTTP then the browser will show giant red warnings.
Can someone please clarify this for me? Is my understanding of HSTS accurate or am I missing something?
HSTS headers should only be issued over HTTPS and only enforced by a User Agent if they are received over HTTPS. A User Agent should disregard the HSTS header sent over HTTP as an attacker could have maliciously injected it.
This means the site can continue to serve over HTTP and the user can continue browsing over HTTP at their choice. However, if they manually insert https:// into the address bar, they will receive the HSTS header and the User Agent will then treat it as a HSTS host.
This is a good way of progressively introducing enforced HTTPS traffic without forcing it all there on day one. As users become aware of the secure option the HTTPS traffic will increase and remain thanks to HSTS. Perhaps the EFF is introducing it gradually and may just flick the big 'HTTPS Switch' one day once they are satisfied they can accommodate it.