How to Configure HSTS Redirect Prerequisites Using CloudFront

amazon-cloudfrontamazon-web-serviceshstsredirect

The HSTS Preload List Submission website has very specific prerequisites which disallow combining protocol changes and redirects into one step (classic example – redirecting requests for http://example.com directly to https://www.example.com fails their test – a protocol upgrade to HTTPS must occur first, then the 'www' subdomain may be added in a discrete step). Is it possible to meet these rules for sites hosted on Amazon CloudFront?

A related question is here, about sending the necessary headers, but I already have that part tested and working. My issue is the redirect, for a site that uses a www subdomain.

I have CloudFront configured to 'Redirect HTTP to HTTPS' under the default behavior and that works perfectly for all HTTP requests, however requests to https://example.com first redirect to the downgraded protocol http://www.example.com before being upgraded to HTTPS, and this is where I am stuck. I need to handle HTTP and HTTPS requests for the second-level domain differently.

For clarity, here is the redirect pattern I want to achieve:

http://example.com > https://example.com > https://www.example.com
http://www.example.com > https://www.example.com
https://example.com > https://www.example.com
https://www.example.com

And here is what CloudFront is doing now, with the third line (protocol downgrade) resulting in HSTS Preload submission failure:

http://example.com > https://example.com > https://www.example.com
http://www.example.com > https://www.example.com
https://example.com > http://www.example.com > https://www.example.com
https://www.example.com

Best Answer

I suspect you may have overlooked the need to purge the CloudFront cache after changing the redirect target protocol to https, because the configuration described (in comments) should work as expected -- setting the "protocol" to "https" in the redirecting bucket's configuration should not do this:

https://example.com > http://www.example.com > https://www.example.com

Create a CloudFront invalidation request using the pattern /*. Once the invalidarion request is complete, as shown in the console, test again. If you still see unexpected behavior, please capture the response headers and edit them into the question.

Related Solutions

Nginx – How to Implement HSTS and Redirect Non-WWW to WWW

HTTP Strict Transport Security (HSTS) can be implemented in two different ways:

1) HSTS by Setting HSTS Headers

Example for Nginx: add_header Strict-Transport-Security "max-age=15768000; preload" always;

First time visitors will get this header and their browsers will redirect internally to HTTPS (see redirect 307 in your network tab, if you inspect the web site). Browsers are caching this HSTS for the given max-age and recurring visitors will use HTTPS if they request your site.

2) HSTS by Preload

For this you can use the service provided by the site https://hstspreload.org/

Here you can add a 2nd level domain (e.g. my-company.com) to a list mainstream browsers will use to load the website via HTTPS. Before you can add a site to this list, this site has to set proper HSTS headers.

Additionally you should consider following details:

removing a domain from the list needs some time and you'd better avoid this
preload includes all sub domains for this 2nd level domain (e.g. www.my-company.com, abc.my-company.com, printer.my-company.com)
HTTP access to subdomains (e.g. for local print services) may not work anymore
beside from above issues HSTS preloading accelerates the access to a website for first time visitors and improves it's security

Regarding redirecting HTTP to HTTPS traffic and HSTS I recommend following setup:

Nginx Virtual Host Config

# HTTPS server section
server {
    listen          443 ssl http2;
    listen          [::]:443 ssl http2;
    server_name     www.my-company.com;

    # include SSL configuration
    include         mycompany-ssl.conf;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }
    ...
}

# redirect HTTPS and non-www requests
server {
    listen          443 ssl http2;
    listen          [::]:443 ssl http2;
    server_name     my-company.com;

    # include SSL configuration
    include         mycompany-ssl.conf;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }

    # default redirect
    location / {
        return      301 https://www.$http_host$request_uri;
    }
}

# redirect HTTP to HTTPS
server {
    listen          80;
    listen          [::]:80;
    server_name     my-company.com www.my-company.com;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }

    # default redirect
    location / {
        return      301 https://$http_host$request_uri;
    }
}

Nginx Include Config for SSL/TLS

ssl                             on;
ssl_protocols                   TLSv1.2;
ssl_ciphers                     "EECDH+AESGCM:EDH+AESGCM:EECDH:EDH:!MD5:!RC4:!LOW:!MEDIUM:!CAMELLIA:!ECDSA:!DES:!DSS:!3DES:!NULL";
ssl_prefer_server_ciphers       on;
# Create session ticket key:    openssl rand -out /etc/nginx/ssl/session_ticket_key 48
ssl_session_ticket_key          /etc/nginx/ssl/session_ticket_key;
# Create dhparam4096.pem:       openssl dhparam -out /etc/nginx/ssl/dhparam4096.pem 4096
ssl_dhparam                     /etc/nginx/ssl/dhparam4096.pem;
ssl_ecdh_curve                  secp384r1;

# Enable SSL stapling
ssl_stapling                    on;
ssl_stapling_verify             on;
resolver                        8.8.8.8 8.8.4.4 valid=1800s;
resolver_timeout                15s;

# set security headers (see http://securityheaders.io/ for more details)
add_header                      Strict-Transport-Security "max-age=15768000; preload" always;
add_header                      X-Frame-Options "SAMEORIGIN" always;
add_header                      X-XSS-Protection "1" always;
add_header                      X-Content-Type-Options "nosniff" always;
add_header                      Referrer-Policy "strict-origin" always;

# set certificate files
ssl_certificate                 /etc/letsencrypt/www.my-company.com/fullchain.pem;
ssl_certificate_key             /etc/letsencrypt/www.my-company.com/privkey.pem;
ssl_trusted_certificate         /etc/letsencrypt/www.my-company.com/fullchain.pem;

HSTS and Double Redirect – Configuration Guide

As noted on the HSTS preload list submission requirements:

Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.

You need to redirect to the same host (ie. HTTP_HOST), not simply to example.com first. You don't need to redirect to example.com if the user is requesting www.example.com directly. (The test will involve a request to example.com.) After that you can redirect to the canonical www subdomain if required.

I tried to add a redirect before the last line, this way:
RewriteRule ^(.*)$ https://example.com/$1 [R,L]

That would create a redirect loop, because the preceding RewriteCond directive only applies to the first RewriteRule, so the second RewriteRule would run unconditionally.

Try something like the following instead:

# HTTP to HTTPS redirect
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]

# Canonical www redirect
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule (.*) https://www.%{HTTP_HOST}/$1 [R,L]

The HTTP_HOST server variable contains the value of the Host HTTP request header (ie. whatever host is being requested).

The 2nd redirect states... for all requests where the requested host does not start www. then prefix www. to the host. However, this might not be acceptable if you have multiple subdomains (that resolve to the same place) you want to keep separate, as they will naturally be redirected to the www subdomain.

Note that these are 302 (temporary) redirects. Change to 301 only when you are sure it's working OK.

And: are there any risks?

No risks. Yes, there are potentially two redirects whereas previously there might have only been one (which is arguably less efficient). But there are still only two redirects, which is perfectly OK for SEO. Besides, with HSTS, the user-agent will only ever experience the double redirect at most once.

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

Aside: (Ignoring HSTS for the moment...) This wouldn't have been complete by itself, as it doesn't canonicalise a request for https://example.com/... (ie. HTTPS and domain apex).

Further reading:

My answer to a related question on Pro Webmasters SE that goes into more detail about implementing HSTS in .htaccess: https://webmasters.stackexchange.com/a/112264/52912

Best Answer

Related Solutions

Nginx – How to Implement HSTS and Redirect Non-WWW to WWW

HSTS and Double Redirect – Configuration Guide

Related Topic