Need feedback for HSTS implementation

    I've implemented HSTS (HTTP Strict Transport Security) and need some feedback. Atm a customer can activate HSTS on certificate add/edit/remove page (/client/cert_view.php?domain_id=*&domain_type=*).
    It's just possible to enable/disable HSTS for that domain. If enabled the apache/domain_ssl.tpl will have an entry like:
    Header always set Strict-Transport-Security "max-age=31536000" (max-age=1year).



    Now my questions:

    • is the max-age ok? Or should it be configurable? If yes: between which values (e.g. just positiv values allowed)?
    • Should I also add the param ; includeSubdomains; preload. If yes: optional (configurable) or fixed?
    • If HSTS is enabled, should http://domain.tld automatically get redirected to https://domain.tld?
      • If yes, fixed or optional?
      • If yes, 301 redirect or still 302 redirect? Should we may then change completely to 301 redirects (also SEO friendly)
    • Should I also add the HSTS rules for domain_disabled_ssl.tld & domain_redirect_ssl.tld?


    Thanks


    PS: After your feedback + modifications I need testers. Then I'll merge "feature-hsts" branch into 1.2.x.

    Well,


    I have tested a little bit. I think max-age is OK. The other questions? Puh, I have no opionion. :)


    BTW: Please check that module headers is enabled a2enmod headers :)

    @Ninos


    See https://github.com/i-MSCP/imscp/pull/46 ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Customer feedback would be also nice. Thread moved to Announcements :-)


    Edit: Thread moved to Suggestions & Wishlist. Sorry, in Announcements users cannot post anything..

    I found this a very great idea that this get inserted in the next i-MSCP release.

    Quote from Ninos

    If HSTS is enabled, should domain.tld automatically get redirected to domain.tld?

    i think this should be done, because if HSTS is enabled and a visitor get the request less https an error will be placed for the visitor (but maybe also configurable but standart on).
    Also all other options i think is better that they can be configurable througt the panel.


    Sry for my bad english, i haven't used google translator because this is worse than my english :D

    @Ninos


    For any improvement of that feature please, create a new branch.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support
    Quote from Ninos

    is the max-age ok? Or should it be configurable? If yes: between which values (e.g. just positiv values allowed)?

    As long as this gives us an A+ Rating at ssllabs.com this setting should be OK. If visiting a site less than once a year is seen as a security problem, reinstalling the OS or buying a new PC also is.


    Maybe setting max-age to 0 should also be possible to allow migrating away from https.


    Quote from Ninos

    Should I also add the param ; includeSubdomains; preload. If yes: optional (configurable) or fixed?

    On one domain, I use quite some subdomains that aren't encrypted, so IMHO includeSubdomains it should be optional. I couldn't find the directive "preload" in RFC 6797, section 6.1.

    Quote from Ninos

    If HSTS is enabled, should domain.tld automatically get redirected to domain.tld?
    If yes, fixed or optional?


    If yes, 301 redirect or still 302 redirect? Should we may then change completely to 301 redirects (also SEO friendly)

    Definitely 301

    Quote from Ninos

    Should I also add the HSTS rules for domain_disabled_ssl.tld & domain_redirect_ssl.tld?

    Yes.

    Thanks for your feedbacks. I've included some of that features into the "feature-hsts"-branch. After reviewing and merging I'll add the possibilities to enable/disable the "includeSubdomains" directive & set a max-age time.


    Quote from f4Nm1Z9k2P

    I couldn't find the directive "preload" in RFC 6797, section 6.1.

    Seems that preload is not needed anymore and the preload lists will be checked by default:
    https://blog.mozilla.org/secur…12/11/01/preloading-hsts/
    http://www.chromium.org/hsts



    PS: I could also change the hsts redirect from 301 to 307 (internal redirect), but I think it's not needed. Again, feedback please :D

    @Ninos


    About sending 307 redirects instead of 302 redirects


    Sending 302 redirects is OK in most of cases because generally, the first request made on a site is a GET request. Thus, the new request issued by the user-agent on the new location stay a GET request (which is expected).


    The problem comes with the sites that provide an API. For instance, if the first request is issued with the POST method and that you send a 302 redirect, the user-agent will automatically issue a new request using the GET method which is bad. Here, your API call will fail due to the wrong HTTP method. Sending a 307 redirect would solve that problem because in that case, the user-agent will issue a new request on the new location using the same method. A POST request will stay a POST request.


    To resume


    Because we are in a shared hosting environment where the customers's web resources are not know by the administrator, we should send 307 redirects instead of 302 redirects, even when using the HSTS feature (307 instead of 301).


    In the case of the HSTS feature, sending a 301 is not really relevant because once the user-agent will receive the HSTS related header, it will force HTTPS request by issuing a 307 redirect internally, according the max-age value.


    Anyway, 302 redirects are almost deprecated (superseded by 303 and 307 redirects). We should only support HTTP/1.1 so 307 should be ok. We are in 2015 after all...


    Finally, the best for 301 redirects would be to:

    • Send 307 redirects for POST requests (it is possible to detect that with Apache)
    • Send 301 redirects for non-POST requests

    Doing this would allow to keep efficiency of 301 redirects for SEO

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    @Ninos


    For me, the max-age value should be lowered and not be greater than 1 month. This would allow to mitigate cases where SSL for a specific site is no longer avialable or just disabled. max-age set to 1 year means that browsers will try to redirect to https during 1 year... Some newbies will never think about their browser cache...

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support