HSTS override in htaccess - anyone seeing same issue?

HSTS caused site to redirect to https ignoring Htaccess redirects

[zbmarshall]

We recently installed SHA2 SSL cert and locked down the server for new PCI compliance requirements (i.e. no more SSLv3 - only TLS) . The server via HSTS then started forcing our whole site to https (basically overriding any redirects in the Htaccess file)

To fix this our web server manager suggested adding to the htaccess file the following line
--------------
## Unset
Header set Strict-Transport-Security "max-age=0"
---------------
..to override the server setting.

Has anyone heard / used the Unset command above for overriding HSTS on the server?
Has anyone seen any problems with htaccess file and the new security protocols with SHA2 and TLS (especially with PCI compliance)?

The command line above fixed our issue but I'm concerned it's only a "bandaid" and not best practice.

Here's our current htaccess file (sitename modified). We're using Magento. Only pages that should be secure are the login, admin, and cart pages. All others should be http. Any suggestions for corrections is greatly appreciated.

#Force www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^Example.com [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301,NC]

# force https for all URLs in /checkout
RewriteCond %{HTTPS} =off
RewriteRule ^checkout https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# don't do anything for images/css/js
RewriteRule \.(gif|jpe?g|png|css|js)$ - [NC,L]

# force http for all other URLs that are not in /checkout
RewriteCond %{HTTPS} =on
RewriteCond %{REQUEST_URI} !^/(checkout|index.php/checkout|admin|index.php/admin|index.php|customer)
RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


## Unset
Header set Strict-Transport-Security "max-age=0"

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule . /index.php [L]

<IfModule mod_deflate.c>

 AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
 AddOutputFilterByType DEFLATE application/xml application/xhtml+xml application/rss+xml
 AddOutputFilterByType DEFLATE application/javascript application/x-javascript
 #AddOutputFilterByType DEFLATE application/x-httpd-php

 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.(?:pdf|doc)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.(?:avi|mov|mp3|mp4|rm)$ no-gzip dont-vary

</IfModule>


<IfModule mod_expires.c>
 
# Enable expirations
 
ExpiresActive On
 
# Default directive
 
ExpiresDefault "access plus 1 month"
 
# My favicon
 
ExpiresByType image/x-icon "access plus 1 year?
 
# Images
 
ExpiresByType image/gif "access plus 1 month"
 
ExpiresByType image/png "access plus 1 month"
 
ExpiresByType image/jpg "access plus 1 month"
 
ExpiresByType image/jpeg "access plus 1 month"
 
# CSS
 
ExpiresByType text/css "access 1 month?
 
# Javascript
 
ExpiresByType application/javascript "access plus 1 year"
 
</IfModule>

[edited by: Ocean10000 at 3:01 pm (utc) on Apr 20, 2015]

[edited by: phranque at 9:32 pm (utc) on Apr 21, 2015]
[edit reason] Unlinking Hyperlink for display [/edit]

[phranque]

welcome to WebmasterWorld, zbmarshall!

The server via HSTS then started forcing our whole site to https (basically overriding any redirects in the Htaccess file)

how did your server do this?
if your server sent the Strict-Transport-Security HTTP Response header then it was the user agent which is forcing the HTTPS: request.

Has anyone heard / used the Unset command above for overriding HSTS on the server?

i believe that directive will only work if it is the user agent's initial request from the server.
the initially sent header will affect the browser for the duration of the initial setting.

[zbmarshall]

Thanks for the welcome phranque

I believe my sentence was incorrect. The server had HSTS enabled. The header was being sent with Strict-Transport-Security "max-age=10886400"

and yes then user's browser (if that's what you mean by "user agent" ) was forcing the https.

I believe that directive will only work if it is the user agent's initial request from the server.

To make sure I understand what you are saying:

When a visitor visits site, If HSTS has max age = X (anything greater than 0), then the browser will force https for that site for X days unless the user clears it out in their browser. When that same visitor comes back to the site, if the HSTS is then set to max age =0, it will not override that visitors settings. Only new visitors will get the new header.

Am I understanding correctly?

[phranque]

If HSTS has max age = X (anything greater than 0), then the browser will force https for that site for X days

max-age is specified in seconds, not days.

I believe that directive will only work if it is the user agent's initial request from the server.

actually i misunderstood the first reference i used.
max-age gets reset every time the header is sent.
here is how mozilla handles HSTS - https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security [developer.mozilla.org]:

Whenever the Strict-Transport-Security header is delivered to the browser, it will update the expiration time for that site, so sites can refresh this information and prevent the timeout from expiring. Should it be necessary to disable Strict Transport Security, setting the max-age to 0 (over a https connection) will immediately expire the Strict-Transport-Security header allowing access via http.

[phranque]

from the RFC - https://tools.ietf.org/html/rfc6797#section-5.3

5.3. HSTS Policy Storage and Maintenance by User Agents
UAs store and index HSTS Policies based strictly upon the domain names of the issuing HSTS Hosts. This means that UAs will maintain the HSTS Policy of any given HSTS Host separately from any HSTS Policies issued by any other HSTS Hosts whose domain names are superdomains or subdomains of the given HSTS Host's domain name. Only the given HSTS Host can update or can cause deletion of its issued HSTS Policy. It accomplishes this by sending Strict-Transport-Security HTTP response header fields to UAs with new values for policy time duration and subdomain applicability. Thus, UAs cache the "freshest" HSTS Policy information on behalf of an HSTS Host. Specifying a zero time duration signals the UA to delete the HSTS Policy (including any asserted includeSubDomains directive) for that HSTS Host. See Section 8.1 ("Strict-Transport-Security Response Header Field Processing") for details. Additionally, Section 6.2 presents examples of Strict-Transport-Security HTTP response header fields.

(i actually found this while looking for the HSTS Policy deletion specification.)

[zbmarshall]

Thank you phranque -- This was extremely helpful. I appreciate it.