In "SSL-required" mode, we should also ship the STS headers to indicate to compatible browsers (firefox 4, firefox+noscript, chromium) that we should never be accessed without SSL. This is called the Strict Transport Security (STS) mode and is documented here:

http://en.wikipedia.org/wiki/Strict_Transport_Security

Here is some sample apache.conf code:

    # Add six earth month HSTS header for all users...
    Header add Strict-Transport-Security "max-age=15768000"
    # If you want to protect all subdomains, use the following header
    # Strict-Transport-Security: max-age=15768000 ; includeSubDomains

... stolen from: https://github.com/ioerror/duraconf/blob/master/configs/apache2/https-hs...

... which varies a little from the canonical wikipedia example:

Header set Strict-Transport-Security "max-age=500"
Header append Strict-Transport-Security includeSubDomains

Comments

omega8cc’s picture

For Nginx it will be:

### Strict Transport Security (ForceHTTPS)
    add_header Strict-Transport-Security "max-age=500; includeSubdomains";

Good idea, IMO, but max-age should be rather short (a few minutes) to avoid issues if the Required mode will be enabled by mistake and admin will revert to Enabled only.

anarcat’s picture

Good.

I think max-age shouldn't be so short, otherwise this becomes much less useful. One way of making sure people know what they're doing would be to add a "strict ssl" option after the "required SSL" one so that it's clear that it's something different, maybe with a tooltip that would explains wtf that is...

omega8cc’s picture

Yes, tooltip there would be useful (maybe with link to Wikipedia?) since not all browsers will understand/support this header.

anarcat’s picture

If a browser doesn't support this feature, then STS is like required SSL, so this is not a problem.

anarcat’s picture

another good code sample: http://pastebin.com/raw.php?i=YZVbSeGg

dkeays’s picture

If you are interested in HSTS but don't have access to Apache2.conf, Coldfrontlabs (coldfrontlabs.ca) has a module for 6 and one for 7. They suggest that if you can then use the lines given above.

One reason for a long expiration time is that the server is insecure when HTTP is being used to connect. Many (if not most) connections will start with one insecure hit which opens them up to a MITM right there. With HSTS that insecurity would only happen once for the life of the header so the attack surface is much smaller.

HSTS does more than just require the browser to contact using HTTPS, it also has zero tolerance for self-signed or invalid certs; it will drop the connection if there is a cert error and there won't be an exception button on the cert error screen. I think the problem was MITM attacks that use an insecure cert on the server to get authenticated and did some social engineering to get ppl to disable cert checking in their browser.

Steven Jones’s picture

Title: add STS headers to SSL-only sites » add STS headers to SSL-only sites (SSL strict mode)
Version: 6.x-0.4-alpha3 » 6.x-2.x-dev
ergonlogic’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Issue summary: View changes

New features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.

bgm’s picture

If anyone is interested, I wrote a small provision sub-module for this:
https://github.com/mlutfy/provision_sts

(I tested agaist Aegir 2.x with Apache, but haven't tested yet with nginx.)

However, I agree with the above comments. It would be nice to have in core, and display a help text on the consequences of enabling STS.

helmo’s picture

Issue tags: +aegir-ssl

Thanks @bgm, I've tested it with Aegir 7.x-3.0beta1 and apache and it works ok.

I've added provision_sts to http://community.aegirproject.org/content/contrib-modules/contribs-aegir...

To be included in Aegir we would probably need to make it configurable. Either global on admin/hosting/settings or per site?

colan’s picture

Just created an Aegir HTTPS issue for this at https://gitlab.com/aegir/hosting_https/issues/35.

helmo’s picture

Status: Active » Closed (duplicate)

That hosting_https issue is now on https://www.drupal.org/project/hosting_https/issues/2936046 lets continue there. Apache works, nginx needs a bit of work.