Difference between revisions of "HTTPS Additional Considerations"
Jump to navigation
Jump to search
(Created page with "==Additional Considerations of HTTPS== ===Website Security=== To protect GC electronic networks, devices and information, the following is a non-exhaustive list of security co...") |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
==Additional Considerations of HTTPS== | ==Additional Considerations of HTTPS== | ||
===Website Security=== | ===Website Security=== | ||
| Line 12: | Line 13: | ||
* Design web services so that they are protected from common security vulnerabilities such as SQL injection and others described in widely-used publications such as the [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Open Web Application Security * Project (OWASP) Top 10]. | * Design web services so that they are protected from common security vulnerabilities such as SQL injection and others described in widely-used publications such as the [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Open Web Application Security * Project (OWASP) Top 10]. | ||
For more information on best practices, refer to [https://www.cse-cst.gc.ca/en/group-groupe/its-advice-and-guidance Communications Security Establishment’s (CSE’s) IT security advice and guidance]. | For more information on best practices, refer to [https://www.cse-cst.gc.ca/en/group-groupe/its-advice-and-guidance Communications Security Establishment’s (CSE’s) IT security advice and guidance]. | ||
| − | |||
| − | |||
| − | |||
| − | === | + | === Your Redirects May Need Some Attention === |
| − | HTTP/ | + | Many redirect domains are currently in use across the GC as a means to provide easy access to specific pages to users, for marketing purposes, or as a proactive measure to protect against phishing and cybersquatting (the act of registering domains you don't intend to actually use, with the hopes of selling for profit). |
| + | |||
| + | There’s no problem with this, however for a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. | ||
| + | |||
| + | '''Problems Seen To Date''' | ||
| + | |||
| + | The following issues are the dominant problems with redirects in the GC: | ||
| + | # Domains don’t redirect to secure versions of themselves first | ||
| + | # Domains redirect to HTTP endpoints similar to themselves instead of HTTPS (eg: http//www) | ||
| + | # Domains redirect to folders on HTTP endpoints rather than HTTPS (eg: http//www/home) | ||
| + | # Redirected HTTPS domains downgrade to HTTP prior to returning to HTTPS (https//root to http//www to https//www) | ||
| + | Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. While an immediate redirect to an HTTPS site will net you "Enforcing HTTPS", there remains issues with other requirements. | ||
| + | |||
| + | When a domain isn't properly secured internally first, it is impossible to provide an HSTS header for that domain, or achieve compliance against cipher and protocol requirements to be used. | ||
| + | |||
| + | '''The Fix''' | ||
| − | + | For each of the redirected URLs, configuration should: | |
| + | # first be permanently redirected to a secure version of itself, with HSTS enabled (<nowiki>http://domain-A</nowiki> --(301)--> <nowiki>https://domain-A</nowiki> (with HSTS)); and then | ||
| + | # permanently be redirected (301) to the HTTPS version of the destination site, with HSTS established there as well (<nowiki>https://domain-A</nowiki> --(301)--> <nowiki>https://final-domain</nowiki> (with HSTS). | ||
| + | While this seems it may be a hassle for users, visitors will only ever get the double redirect once due to HSTS. | ||
| − | + | Ideally your redirected domains and eventual destination domain both reside on the same server and are internal redirects to a subdomain (domain root --> www, or other), which allows you to add your redirect domains to the Subject Alternative Name (SAN) field when setting up your certificate for your primary site to include all of your pointed URLs, rather than having to get certificates for each one. | |
| − | + | When redirecting to Canada.ca, or another major GC hub you may not/do not have control over, the configuration of the eventual domain is not your responsibility, nor will the results for that domain be reflected in your domain results. Your domain must be configured appropriately on the server it resolves to reach full compliance. | |
| − | |||
| − | |||
| − | |||
| − | + | If you need guidance on this, please refer to our Certificates section in the [[:en:GC_HTTPS_Everywhere/Implementation_Guidance|HTTPS Implementation Guidance]].<br><br> | |
| − | + | '''Additional Guidance:''' [https://www.us-cert.gov/ncas/tips/ST18-006 Website Security | US-CERT] | |
| − | <br | + | <br><br> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | <br | ||
| − | |||
| − | <br | ||
Latest revision as of 10:29, 8 February 2021
Additional Considerations of HTTPS
Website Security
To protect GC electronic networks, devices and information, the following is a non-exhaustive list of security considerations that can be implemented in a layered manner to support a defence-in-depth approach for web services and minimize opportunities for cyber attacks:
- Deploy modern operating systems (OS) and applications that are maintained with supported, up-to-date, and tested versions of software.
- Actively manage software vulnerabilities, including fixing known vulnerabilities quickly following a timely patch maintenance policy for OS and applications, and taking other mitigating steps, where patches can’t be applied.
- Implement appropriate host-based protections to protect systems against both known and unknown malicious activity.
- Minimize available services and control connectivity by removing or disabling all non-essential ports and services as well as removing unnecessary accounts from systems.
- Enable system logging to improve the ability to detect and identify anomalous behaviours, perform system monitoring, and to assist with incident response and forensic analysis of compromised systems.
- Carefully control and manage privileges assigned to users and administrators. Provide a reasonable (but minimal) level of system privileges and rights needed for their role.
- Use strong authentication mechanisms (for example, multi-factor authentication) where possible to protect from unauthorized access.
- Design web services so that they are protected from common security vulnerabilities such as SQL injection and others described in widely-used publications such as the Open Web Application Security * Project (OWASP) Top 10.
For more information on best practices, refer to Communications Security Establishment’s (CSE’s) IT security advice and guidance.
Your Redirects May Need Some Attention
Many redirect domains are currently in use across the GC as a means to provide easy access to specific pages to users, for marketing purposes, or as a proactive measure to protect against phishing and cybersquatting (the act of registering domains you don't intend to actually use, with the hopes of selling for profit).
There’s no problem with this, however for a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain.
Problems Seen To Date
The following issues are the dominant problems with redirects in the GC:
- Domains don’t redirect to secure versions of themselves first
- Domains redirect to HTTP endpoints similar to themselves instead of HTTPS (eg: http//www)
- Domains redirect to folders on HTTP endpoints rather than HTTPS (eg: http//www/home)
- Redirected HTTPS domains downgrade to HTTP prior to returning to HTTPS (https//root to http//www to https//www)
Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. While an immediate redirect to an HTTPS site will net you "Enforcing HTTPS", there remains issues with other requirements.
When a domain isn't properly secured internally first, it is impossible to provide an HSTS header for that domain, or achieve compliance against cipher and protocol requirements to be used.
The Fix
For each of the redirected URLs, configuration should:
- first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then
- permanently be redirected (301) to the HTTPS version of the destination site, with HSTS established there as well (https://domain-A --(301)--> https://final-domain (with HSTS).
While this seems it may be a hassle for users, visitors will only ever get the double redirect once due to HSTS.
Ideally your redirected domains and eventual destination domain both reside on the same server and are internal redirects to a subdomain (domain root --> www, or other), which allows you to add your redirect domains to the Subject Alternative Name (SAN) field when setting up your certificate for your primary site to include all of your pointed URLs, rather than having to get certificates for each one.
When redirecting to Canada.ca, or another major GC hub you may not/do not have control over, the configuration of the eventual domain is not your responsibility, nor will the results for that domain be reflected in your domain results. Your domain must be configured appropriately on the server it resolves to reach full compliance.
If you need guidance on this, please refer to our Certificates section in the HTTPS Implementation Guidance.
Additional Guidance: Website Security | US-CERT
