Increase HSTS max-age to default to one year

[migg24]

What this PR does / why we need it:

Increase hsts-max-age to secure default of 1 year, as this is the required minimum duration by several tools checking for header setup (like internet.nl). Currently people have to manually set hsts-max-age to one year, but I think this chart should come with a secure default.

It is also the minimum duration to activate preload (see https://hstspreload.org/).

It is also the recommended max-age on https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Not sure if this qualifies as breaking change as it technically changes existing functionality but only the duration of the header.

Which issue/s this PR fixes

How Has This Been Tested?

Not tested, replaced all occurences of 15724800 in the repo.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: migg24 / name: Michael Dreher (9dbb9cb)

[netlify]

✅ Deploy Preview for kubernetes-ingress-nginx ready!

Name	Link
🔨 Latest commit	9dbb9cb
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-ingress-nginx/deploys/6538e513597557000868ffe4
😎 Deploy Preview	https://deploy-preview-10564--kubernetes-ingress-nginx.netlify.app/user-guide/nginx-configuration/configmap
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

Welcome @migg24!

It looks like this is your first PR to kubernetes/ingress-nginx 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/ingress-nginx has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @migg24. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[strongjz]

/lgtm
/cherry-pick release-1.9

[k8s-infra-cherrypick-robot]

@strongjz: once the present PR merges, I will cherry-pick it on top of release-1.9 in a new PR and assign it to you.

In response to this:

/lgtm
/cherry-pick release-1.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: migg24, strongjz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [strongjz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-infra-cherrypick-robot]

@strongjz: new pull request created: #10580

In response to this:

/lgtm
/cherry-pick release-1.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[rikatz]

Do we really wanna cherry-pick it? Can this be a breaking change?

[tao12345666333]

Increasing the NGINX HSTS (HTTP Strict Transport Security) max-age has the following effects on website security and users:

1. Longer secure connection periods: Increasing the max-age value will make browsers automatically convert HTTP requests to HTTPS requests for a longer period, improving the security of your website.

2. Reduced risk of man-in-the-middle attacks: By using HSTS and increasing the max-age value, you can lower the risk of users being subjected to man-in-the-middle attacks, as the secure connection will persist for a longer time.

3. Caching policy: A larger max-age value means that browsers will cache the HSTS settings for a longer period. This can have implications for user privacy, especially when they are using public computers or networks.

4. Difficulty in revoking: After increasing the max-age value, if you decide to stop using HTTPS, you may encounter issues, as browsers will still attempt to use HTTPS to access the website for the duration of the max-age period. In this case, if you do not have a valid SSL certificate, users may encounter warnings or problems accessing the site.

5. Slower first-time access: Although increasing the max-age value can improve security, users may experience slightly slower loading speeds when visiting the website for the first time, as the browser needs to redirect to HTTPS. However, once the user has visited the site, this issue is mitigated.

Maybe we can release it in the next version and alert users in the Changelog?