Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Warning: Unnecessary HSTS header over HTTP

Tags:

.htaccess

hsts

I want to use https:// and non www. URL always. So I used the following code in my htaccess file. But i am getting an warning from https://hstspreload.org

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]    

<ifModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000;
includeSubDomains; preload" 
</ifModule>

Warning Message is given bellow :

Warning: Unnecessary HSTS header over HTTP
The HTTP page at http://mysiteurl.com sends an HSTS header. This has no effect over HTTP, and should be removed.

Please help me to rid the above warning. I tried with the following code also but it does not work #ref. topic

 Header always set Strict-Transport-Security "max-age=31536000; 
 includeSubDomains; preload" env=HTTPS
like image 871
Md Nurullah Avatar asked Jul 10 '17 22:07

Md Nurullah


People also ask

Is HSTS header necessary?

This removes the opportunity an attacker has to intercept and tamper with redirects over HTTP. The HSTS response header is still needed in this scenario and must be left in place for those browsers that don't use preloaded HSTS lists.

How do I resolve HSTS missing from HTTPS server?

Use your browsers developer tools or a command line HTTP client and look for a response header named Strict-Transport-Security. Access your application once over HTTPS, then access the same application over HTTP. Verify your browser automatically changes the URL to HTTPS over port 443.

How do I turn off HTTP Strict Transport Security?

Clearing HSTS in Chrome Open Google Chrome. Search for chrome://net-internals/#hsts in your address bar. Locate the Query HSTS/PKP domain field and enter the domain name that you wish to delete HSTS settings for. Finally, enter the domain name in the Delete domain security policies and simply press the Delete button.


1 Answers

Try removing the always attribute. So do this:

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

Instead of this:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

The other option is to only set this in the HTTPS VirtualHost's rather than in the main top level config:

Do this:

<VirtualHost *:443>
    (All other virtual host config)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Instead of this:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
<VirtualHost *:443>
    (All other virtual host config)
</VirtualHost>

This has the disadvantage (or advantage depending how you look at it!) of having to be added to each VirtualHost to take effect, whereas the first option would automatically be applied to all HTTPS virtual hosts.

And please, please, please be very careful with preload. It is not easily reversible! I would strongly recommend you run for a few months with good (i.e. error-free) config - which it appears you have not been doing - before submitting to preload list.

To give one example where preload can cause you problems: Supposing you run https://www.example.com, and this also responds to http://example.com and redirects you to https://example.com and then https://www.example.com (as the preload submissions require and as your config is set up to do). Then your website is lovely and secure. However, for companies that reuse their domain internally (which is quite common) this can cause problems - especially when you preload. For example, if you run a non-secure site which is not publicly available at http://intranet.example.com, or perhaps a non-secure development version of your site at http://dev.example.com, then you may not realise that this site must now also be served over HTTPS (as it is a subdomain of example.com). This rarely takes effect (as most people don't visit http://example.com or https://example.com so never see this HSTS header on top level domain) so you might never notice this potential problem during all your testing. However as soon as the preload takes effect, your browser will then know about the HSTS at top level domain even without visiting that and you instantly lose access to those HTTP-only sites, and cannot easily reverse this! Lots of companies still have lots of internal sites and tools served over HTTP only and upgrading them all to HTTPS (which should be done anyway btw!) at short notice would not be easy.

To get around this, either use a different domain internally, or you can only set this without includeSubDomain on the top level domain:

<VirtualHost *:443>
    ServerName example.com
    (All other virtual host config)
    #Set HSTS at top level without includeSubDomain
    Header always set Strict-Transport-Security "max-age=31536000"
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    (All other virtual host config)
    #Set HSTS at subdomain level
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

This is not quite as secure (as someone can set up other subdomains over HTTP like http://wwww.example.com (note the four Ws) or http://fake.subdomain.com) but at least it doesn't break those HTTP-only sites. This setup will not be allowed through the preload list as it demands the more secure includeSubDomains even on the top level domain.

If you do want to use includeSubDomains even on the top level domain then I strongly recommend including a resource from the top level domain in your HTML (even if it redirects to the www version as HSTS is still set for 301s/302s). This way you are making sure visitors load the HSTS config at top level even before you preload. For example you could replace your logo to a call to the top level domain instead:

<img source="https://example.com/logo.png">

Run with that, and a small expiry, and no preload tag for a bit. Then increase the expiry. Then, if that all works, add the preload tag back and submit to the preload list.

This might all sound a bit painful, and perhaps you've thought of all this, but preloading can be incredibly dangerous if not thought through, due to the fact it is not easily reversible. In my opinion preloading HSTS is overkill for most sites though I agree it is the most secure option.

like image 121
Barry Pollard Avatar answered Sep 22 '22 06:09

Barry Pollard