Search code examples
sslnginxsettingshsts

nginx ssl and hsts setting

I would like to redirect for http to https and use hsts

https://hstspreload.org/
(test failed)Error: No HSTS header Response error: No HSTS header is present on the response.

At the same time how can I redirect and hsts setting?

P.S I have set up load balancing with aws ssl certificate and elb.

/etc/nginx/conf.d/default.conf

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name My_domain;

if ($http_x_forwarded_proto = "http") {
    return 301 https://$server_name$request_uri;
}

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ /index.html;
}

location /api/ {
    proxy_pass              http://localhost:8080;
}

server {
    listen 443 ssl;
    server_name My_domain;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}
Solution

  • You haven't given enough information as to your set up, but I can take a guess at what is going on.

    I would guess you you are offloading your SSL at your ELB and sending plaintext HTTP messages to Nginx with the HTTP_X_FORWARDED_PROTO header set to the original scheme.

    So if the user goes to https://www.example.com then it offloads the SSL/TLS and directs traffic to http://www.example.com with the HTTP_X_FORWARDED_PROTO set to "https". In this scenario there is no redirect (as user is already using HTTPS) but also no HSTS header (as user is not using HTTPS to nginx and you only set that header in your 443 server config). You should add this to your port 80 server to also serve the HSTS header for this scenario:

    if ($http_x_forwarded_proto = "https") {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

    Technically you should not serve the HSTS header over HTTP and only over HTTPS, so this would be better set at the load balancing level but I think with the $http_x_forwarded_proto header this is OK.

    However, if my guess is correct, then this proves that you are not using HSTS correctly so it would be remiss of me not to add some warning here.

    HSTS is not without risks.

    HSTS is a great thing to address the fact that, currently, the web is not HTTPS by default and this leads to various security risks. However it is not without risks if you ever still need to use HTTP. For example if you have some subdomains you have not converted to HTTPS yet (e.g. blog.example.com), or if you use the same domain for internal sites you have not converted yet (e.g. intranet.example.com) or development sites (dev.example.com). The last can also be a problem because HSTS does not allow you to skip past HTTPS errors (e.g. if using a self-signed certificate for your dev domains). That's not to say you shouldn't use HSTS - but you should understand it fully and test it before you cause yourself (and your organisation) lots of pain.

    For this reason it is recommended to start with a small max-age and not go for the full year (max-age= 31536000) and build up. Rather than go with the full amount and break things. That way if you find a site that needs converting, you've not locked it out for a year or until you convert to HTTPS.

    This is especially true for preload, where you bake the header into browsers code base so it's on from the beginning even before you have visited the site. You basically cannot undo this (Chrome will take at least 3 months to remove it and other browsers give no timeline). So, as it's basically irreversible, you should NEVER go for preload until you've full tested it, which it looks like you have not. Chrome has an issue tracking all the screw ups that sites have done where they have requested preload and then broken things. I've blog about this danger, as have others. Additionally preload has some other requirements (you must add the preload attribute to your header and you must serve this header over your base domain (https://example.com) as well) which you do not appear to be meeting.

    The base domain issue can especially cause problems if, for example, you never visit that normally so testing of https://www.example.com looks fine and http://intranet.example.com still works (as you've never set the HSTS header at the base domain so it can continue to be sent over HTTP) and then you preload and boom - http://intranet.example.com stops working. The easiest way to test this is to add a resource from this base domain to your www site (e.g. https://example.com/pixel.png) which will force the HSTS header for the base domain for anyone that visis your site.

    HSTS is great. Every site should be using it and every site should only be using HTTPS - but until they do it's not without risks. Make sure you understand it when deploying it. And take it slow and build up a large max-age. And only then go for preload.