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.
Related
If your web server implements HTTPs, it's common practice to 301 redirect all http://* URLs to their https:// equivalents.
However, it occurs to me that this means that the client's original HTTP request (and any data contained in it) remains fully unencrypted, and only the response is encrypted. Does automatically "upgrading" all insecure requests on the server end effectively encourage clients to continue sending data to insecure HTTP endpoints, more or less downgrade attacking myself?
I realize I can't stop a client from insecurely sending any data to any endpoint, but does the practice of automatically redirecting HTTP to HTTPS "condone" the client doing so? Would it be better practice to instead outright reject all HTTP traffic that could contain sensitive data and make it the browser's responsibility to attempt or recommend the upgrade to HTTPS?
This is indeed a known issue, and HTTP Strict Transport Security (HSTS)—released in 2012—aims to solve it. It is an HTTP header field which takes the form:
Strict-Transport-Security: max-age=<seconds> [; includeSubDomains]
HSTS informs the browser via that all connections to a given domain must be "upgraded" to https, even if they were specified as non-secure http`:
The UA MUST replace the URI scheme with "https"
This applies to all future connections to the domain (including following links), for the duration of the max-age specified in the header.
However this does leave open a potential vulnerability on the user's first visit to a domain with HSTS (if the header were stripped by an attacker). Google Chrome, Mozilla Firefox, Internet Explorer and Microsoft Edge attempt to limit this problem by including a "pre-loaded" list of HSTS sites.
So this preloaded list has all popular websites, All you may see in this chromium link, this list is humongous(10M), thereby solving aforementioned problem to a certain extent.
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.
I have a sdk and want to support both http and https, but browsers always force to https. I know that is good feature of browser but many websites using http could not use my sdk.
Does anyone know how I can prevent HSTS or a solution for this?
HSTS is activated only when the concerned website ask for it (or when the user add the website manually to his browser). So if HSTS is enable, it's because the website support https (HSTS header is only valid when set on a secure https response).
If the website doesn't provide http you can't force it. (and when using HSTS, all http request bypassing HSTS will probably get a redirect to https as an answer)
Note that if the HSTS header have the 'includeSubdomains' options, it will force https for all subdomains, even if they don't support https.
Last point : HSTS (and HTTPS) is a security feature, it's probably a bad idea to try disable it.
I work on an application where users can embed their website within surrounding content by loading it in an iframe. This obviously relies on the X-Frame-Options not being set on the users website to work. I was asked by a client to create a reverse proxy because they didn't want to remove the X-Frame-Options header from their site for security concerns.
I setup the proxy and everything works but what's the point of the X-Frame-Options header if its as simple as creating a proxy to circumvent?
I understand the header exists to prevent clickjacking but if anyone can just make a proxy to workaround it... does it really increase security?
I don't come from the enterprise dev world, can you help me understand the reasoning behind why the IT department would be resistant to removing the header?
I noticed google.com and facebook.com also set the header, so it can't be completely pointless can it?
Thanks
Any site served over http can have its content altered by using a proxy for example. So yes this is fairly pointless on http sites since it's so easily defeated.
Serving a site over https prevents this unless you have a proxy server which also intercepts https traffic. This is only possible by the proxy acting as a man-in-the-middle (MITM) so it decrypts the traffic at the proxy and then re-encrypts the traffic to send on to the server and same in way back. For this to work the proxy server either needs to know the server private key or, more likely, replaces the cert presented to its client with its own copy.
While MITM is usually associated with attacks there are some legitimate scenarios (though many argue even these are not legitimate and https should be secure!):
Anti-virus software can do this to scan requests to protect your computer. If you run Avast for example and have SSL scanning turned on (think it's on by default) and go to https://www.google.com and look at the cert you will notice it's been issued by Avast instead of by Google as usual. To do this requires the antivirus software to have installed an issuer certificate on your PC from which it can issue these replacement certs which your browser will still accept as real certs. Installing this issuer cert requires Admin access which you temporarily give when installing the anti-virus software.
Corporate proxies do a similar process to allow them to monitor https traffic from its employees. Again it requires an issuer installed on the PC using admin rights.
So basically it's only possible to use a proxy like you suggest for https traffic if you already have, or have had in the past, Admin rights in the PC - at which case all bets are off anyway.
The only other way to do this is to keep traffic on http using a proxy. For example if you request www.google.com then this normally redirects to https://www.google.com but your proxy can intercept that redirect request and instead keep the client->proxy connection on https, allowing the proxy to amend the request to strip out headers. This depends on the users not typing https, not noticing there is no green padlock and can be defeated with technologies like HSTS (which is automatically preloaded in some browsers for some sites like google.com). So not really reliable way to intercept traffic.
Many secure sites use X-Frame-Options to prevent clickjacking
Clickjacking
Clickjacking Defense Cheat Sheet
This prevents attackers from tricking users through transparent layers from performing actions they are unaware of on sites they didn't even know they loaded. Furthermore, this attack only works with frames that are directly served from the attacked/victim site's domain in the user's browser.
You may think that you can just reverse proxy the site and remove the frame busting header. But your proxy is not receiving or sending the end users cookies to the victim site. These secure sites rely on an active session, and as such will interpret the request from the proxy as coming from an unauthenticated user completely defeating the point of clickjacking.
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.