https://wiki.gccollab.ca/api.php?action=feedcontributions&user=Tim.allardyce&feedformat=atomwiki - User contributions [en]2024-03-28T21:05:23ZUser contributionsMediaWiki 1.35.2https://wiki.gccollab.ca/index.php?title=Tim_Allardyce&diff=30730Tim Allardyce2020-08-06T15:34:50Z<p>Tim.allardyce: Created page with "Page for Tim Allardyce! Do you have one too?"</p>
<hr />
<div>Page for Tim Allardyce! Do you have one too?</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Tim.allardyce&diff=30728Tim.allardyce2020-08-06T15:34:01Z<p>Tim.allardyce: Created page with "Page for Tim Allardyce! Do you have one too?"</p>
<hr />
<div>Page for Tim Allardyce! Do you have one too?</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_Enterprise_Architecture/Framework&diff=14553GC Enterprise Architecture/Framework2019-12-06T16:08:27Z<p>Tim.allardyce: </p>
<hr />
<div>{{OCIO_GCEA_Header}}<br />
<br />
<i><h3> This is a <b><u>DRAFT COPY</u></b> of the proposed updates to the GC EA standards</h3></i><br />
<br />
<big>Changes from the [[Government of Canada Architectural Standards|previous version]] are marked as <u>underlined</u> and new additions are marked as <u>''italic and underlined''</u></big><br />
<br />
<br />
The GC Enterprise Architecture standard is part of the [https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249 Directive on Management of Information Technology]. It is listed as [https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249 Appendix C - Mandatory Procedures for Enterprise Architecture Assessment] in the Directive.<br />
<br />
{| width="100%" cellpadding="10" cellspacing="15px"<br />
<br />
|- valign="top"<br />
| style="border-left: 10px solid #c5d5af; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); color: black; background-color: white; font-size:1.2em;" | <br />
<span style="font-size: 1.5em;">[[GC_Business_Enterprise_Architecture | 1. Business Architecture]]</span> <br><br><br />
<br />
<b><u>Fulfillment to the needs of the stakeholders to the Government of Canada </b><br />
* <I>Understand stakeholders well, conduct stakeholder analysis and create stakeholder mapping for each service being delivered<br />
* Ensure stakeholders' needs are clearly identified and captured for each service </I></u><br />
* Ensure accountability for privacy is clear<br />
* <u><I>Ensure gender diversity and inclusion are considered as part of an intersectional approach to designing the service. Consult the Policy Direction to Modernize the Government of Canada’s Sex and Gender Information Practices and best practices for gender inclusive language<br />
* Adopt a client-centric view of business delivery of service through customer journey maps and end-to-end service decomposition (internal (GC) and external (public)) </I></u><br />
<br />
<br />
<b><u> Focus on Business Outcome and Strategic Alignment to the Department and to the Government of Canada </b><br />
* <I>Establish business architecture early, focusing on business services and capabilities to eliminate technological constraints from transformation designs and roadmaps <br />
* Use tools, such as Value Stream, to ensure business outcomes are achieved through services being delivered</I></u><br />
* Model <I><u> operation flow for each service being delivered in a business process modeling tool, using departmental chosen standard for business process notation, such as </u></I> Business Process Modeling Notation (BPMN), <I><u> and find optimization in the business process first<br />
* Ensure business requirements collection are completed prior to considering options<br />
* Conduct option analysis from a business lens and ensure all options are considered prior to select the best solution to achieve business outcomes </u></I><br />
<br />
<br />
<b><u> Horizontal Enablement </b><br />
* <i>Use business processes developed to identify common enterprise processes <br />
* Optimize common enterprise processes and maximize its re-use</i></u><br />
* Encourage and use <u><i>a process (for example:</i></u> Test Driven Development (TDD)) to improve the trust between Business and IT<br />
<br />
<br />
<b>Align to the [https://gcconnex.gc.ca/file/view/50303099/gcbcm-gcmca-v2-visualmodel-20190617-en-pdf?language=en GC Business Capability model]</b><br />
* Define program services as business capabilities to establish a common vocabulary between business, development, and operation<br />
* <u><I>Translate business strategy into business capability implications using the GC Business Capability Model<br />
* Use the GC Business Capability Model as a baseline and refine the capabilities to deeper levels that are applicable to the departmental use<br />
* Identify frequently used business capabilities to identify area of focus in resource and skills requirement (Resource Management) for the department as well as to guide investments<br />
* Identify common business capabilities that can be leveraged by the GC enterprise and share it with the community for possible collaboration through a working group </I></u><br />
|}<br />
<br />
{| width="100%" cellpadding="10" cellspacing="15px"<br />
<br />
|- valign="top"<br />
| style="border-left: 10px solid #f4d177; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); color: black; background-color: white; font-size:1.2em;" | <br />
<span style="font-size: 1.5em;">[[GC_Information_Enterprise_Architecture| 2. Information Architecture]]</span> <br><br><br />
<br />
<b>Data Collection</b><br />
* Ensure data is collected <I><u> responsibly and </I></u>in a manner that maximizes use, <I><u>reuse</I></u> and availability of data<br />
* Align to existing enterprise and international standards, <I><u> or where none exist, develop standards in the open with key subject matter experts </I></u>and consultation with Enterprise Data Community of Practice</u></I><br />
* <I><u>When collecting personal data or information, ensure that your practices are responsible and align with enterprise data ethics standards as well as relevant policy and legislation. The Policy Direction to Modernize the Government of Canada’s Sex and Gender Information Practices is an example of relevant policy that can inform considerations of gender diversity and inclusion. </I></u><br />
* <I><u>Ensure data is collected only if it cannot be obtained through data-sharing</I></u><br />
* Ensure that data collection <I><u>methodology</I></u> yields high quality data <I><u>in alignment with enterprise data standards</I></u><br />
* <I><u>Engage with key stakeholders within the federal government, as well as provincial, territorial and </I></u> other levels of government, including indigenous people<br />
* <I><u>Adopt a needs-based approach to data collection and review existing data assets prior to collecting or acquiring new data</i></u><br />
* <I><u>Ensure access and quality provisions are in place for data collected or acquired through third-party contracting services</I></u><br />
<br />
<b>Ensure that Data is Managed Responsibly and in a manner that Maximize Use, Reuse and Availability of Data</b></I></u><br />
* Align with enterprise and departmental policies and standards on data <I><u>architecture</u></I> and governance<br />
* <I><u>Enable discoverability, accessibility, resiliency and availability of the departmental data assets<br />
* Asses, control and monitor data quality in alignment with enterprise data standards<br />
* Define and establish clear roles, responsibilities and accountabilities for data management<br />
* Where possible, use automation to support the management of data<br />
* Identify and document the lineage of the departmental data assets<br />
* Regularly assess the value of the departmental data assets and undertake retention and disposition as per existing schedules<br />
* Only handle data which is essential to your service. Do not store all data that you capture unless absolutely necessary</i></u><br />
* Ensure data is stored in a secure manner in accordance with <I><u>CSE approved cryptographic algorithms and protocols and legislation such as</I></u> the Privacy Act<br />
* <I><u>Manage departmental data in a way that enables interoperability, not only within the department, but also at the enterprise level</u></I> <br />
* Ensure that data is used in an Ethical and Secure manner<br />
* Ensure that combined data does not risk identification or re-identification of sensitive or personal information<br />
* Ensure the data is fit for the use it is employed for in accordance with data quality guidelines <br />
* Inform decisions by the appropriate data and information</I></u><br />
<br />
<b>Data Sharing</b><br />
* Data should be shared openly by default as per the Directive on Open Government<br />
* <I><u>If data cannot be shared, explicitly state the laws and/or regulations preventing its sharing <br />
* Ensure that any data you share adheres to existing <I><u>enterprise and international standards, including on quality or fitness for purpose</I></u><br />
* Encourage data sharing and collaboration<br />
* <I><u>Ensure that data received from external parties is profiled and validated prior to its use.<br />
* Enable internal and external sharing of data and information as appropriate</I></u><br />
|}<br />
<br />
{| width="100%" cellpadding="10" cellspacing="15px"<br />
<br />
|- valign="top"<br />
| style="border-left: 10px solid #f5844e; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); color: black; background-color: white; font-size:1.2em;" | <br />
<span style="font-size: 1.5em;">[[GC_Application_Enterprise_Architecture | 3. Application Architecture]]</span> <br><br><br />
<br />
<b>Use Open Standards and Solutions by Default</b><br />
* Where possible, use open source standards, and open source software first<br />
* <I><u>When using Open Source remain at the latest and greatest version to ensure any security vulnerabilities are patched</u></I><br />
* <I><u>Ensure any extension or change to the Open Source item is contributed back to the community</u></I><br />
* If an Open Source option is not available or does not meet user needs, favour platform-agnostic COTS over proprietary COTS, avoiding technology dependency, allowing for substitutability and interoperability<br />
* If a custom-built application is the appropriate option, by default any source code written by the government must be released in an open format via Government of Canada website and services designated by the Treasury Board of Canada Secretariat<br />
* All Open Source code must be released under an appropriate open source software license<br />
* <I><u>Ensure valid license and legal requirements are met for use of Open Source items</u></I><br />
* Expose public data to implement Open Data and Open Information initiatives<br />
<br />
<br />
<b>Design for Users First and Deliver with Multidisciplinary Teams</b><br />
* Focus on the needs of users, using agile, iterative, and user-centred methods<br />
* Conform to both accessibility and official languages requirements<br />
* Include all skillsets required for delivery, including for requirements, design, development, and operations<br />
* Work across the entire application lifecycle, from development and testing to deployment and operations<br />
* Ensure quality <u><i>and security</i></u> is <u><i>underpinning</i></u> the Software Development Lifecycle<br />
* <I><u>Total Cost of Ownership (TCO) should include the cost for design, construction, operation, and maintenance of a system. For example Training, Support, Disaster Recovery, and Retirement Cost</I></u><br />
<br />
<br />
<b><u>Design Systems to be Measurable and Accountable</b></u><br />
* Publish performance expectations for each business service and supporting application and technology service(s)<br />
* Make an audit trail available for all transactions to ensure accountability and non-repudiation<br />
* Establish business and IT metrics to enable business outcomes<br />
* Apply oversight and lifecycle management to digital investments through governance<br />
* <u><I>Complete an Algorithmic Impact Assessment (AIA) for systems automating decisions as per the [https://tbs-sct.gc.ca/pol/doc-eng.aspx?id=32592 Directive on Automated Decision-Making].</u></I><br />
<br />
<br />
<b>Maximize Reuse</b><br />
* <I><u> Reduce integration Complexity - design systems to be highly modular and loosely coupled to be able to reuse components. </I></u><br />
* Leverage and reuse existing solutions, components, and processes<br />
* Select enterprise and cluster solutions over department-specific solutions<br />
* Achieve simplification by minimizing duplication of components and adhering to relevant standards<br />
* Inform the GC EARB about departmental investments and innovations<br />
* Share code publicly when appropriate, and when not, share within the Government of Canada<br />
* <u>Use micro services scoped to a single purpose <I>and made available for cross-business use</u></I><br />
<br />
<br />
<b>Enable [https://www.gcpedia.gc.ca/wiki/En/GCinterop Interoperability]</b><br />
* Expose all functionality as services<br />
* <u><I>Make all </i></u> services <I><u>available </u></i> through a well-defined interface, such as a HTTPS-based [https://www.canada.ca/en/government/publicservice/modernizing/government-canada-standards-apis.html application programming interface (API)]<br />
* <u><I> Design APIs according to the Mandatory Procedures for Application Programming Interfaces (Government of Canada API Standards)<br />
* All APIs with potential for cross-departmental, inter-jurisdictional, or public consumption must be published to [https://api.canada.ca/en/homepage | the GC API Store] <br />
* Use the [gccollab:groups/profile/1238235/engovernment-of-canada-digital-exchangefru00c9change-numu00e9rique-du-gouvernement-du-Canada | Canadian Digital Exchange Platform (CDXP)] for data exchange where suitable (e.g. GC Event Broker for asynchronous messaging)<br />
<br />
<br />
<b>Develop with Security in mind</b><br />
* Applications that store, process, handle, or have network access to sensitive information should be developed with security in mind from the start, and should be audited and assessed before use<br />
* Ensure sensitive data is protected appropriately when stored and transmitted (Duplicate D3)<br />
* Minimise the opportunity for accidental data leakage across application boundaries<br />
* Ensure only authorised parties can access sensitive information<br />
* Log access to facilitate audits and isolate unauthorized behaviour<br />
* Restrict access to sensitive data to those applications designed to handle such material in a secure manner</u></I> <br />
|}<br />
<br />
{| width="100%" cellpadding="10" cellspacing="15px"<br />
<br />
|- valign="top"<br />
| style="border-left: 10px solid #cb6d49; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); color: black; background-color: white; font-size:1.2em;" | <br />
<span style="font-size: 1.5em;">[[GC_Technology_Enterprise_Architecture | 4. Technology Architecture]]</span> <br><br><br />
<br />
<b>Use Cloud first</b><br />
* <I><u>Adopt the Use of the GC Accelerators to ensure proper Security and Access Controls - [https://github.com/canada-ca/accelerators_accelerateurs-azure Azure], [https://github.com/canada-ca/accelerators_accelerateurs-aws AWS]</u></I><br />
* Enforce this order of preference: Software as a Service (SaaS) first, then Platform as a Service (PaaS), and lastly Infrastructure as a Service (IaaS)<br />
* Enforce this order of preference: Public cloud first, then Hybrid cloud, then Private cloud, and lastly non-cloud (on-premises) solutions<br />
* Design for cloud mobility and develop an exit strategy to avoid vendor lock-in<br />
<br />
<b>Design for Performance, Availability, and Scalability</b><br />
* Design for resiliency<br />
* Ensure response times meet user needs, and critical services are highly available<br />
* Support zero-downtime deployments for planned and unplanned maintenance<br />
* Use distributed architectures, assume failure will happen, handle errors gracefully, and monitor <u><I>performance and behaviour </I></u> actively<br />
* <u>Run applications in containers <I> to enable rapid deployment and scaling<br />
* Establish architectures that supports new technology insertion with minimal disruption to existing programs and services<br />
* Control Technical Diversity - design systems based on modern technologies and platforms already in use.</I></u><br />
|}<br />
<br />
{| width="100%" cellpadding="10" cellspacing="15px"<br />
<br />
|- valign="top"<br />
| style="border-left: 10px solid #996782; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); color: black; background-color: white; font-size:1.2em;" | <br />
<span style="font-size: 1.5em;">[[GC_Security_and_Privacy_Enterprise_Architecture | 5. Security Architecture and Privacy]]</span> <br><br><br />
<br />
<I><u><br />
<b>Build Security into the Full System Life Cycle, Across All Architectural Layers</b><br />
* Identify and classify risks associated to the service’s business objectives, goals, and strategy<br />
* Design security measures according to business and user needs, risks identified, and security categorization of the information and assets; integrate security across all architectural layers (BIAT). <br />
** Maintain focus on users’ ease of use through selection of context-appropriate controls<br />
** Apply an information-centric approach to reduce resources’ exposure to threats, and minimize the opportunity for compromise. <br />
** Protect data while in transit, in use and at rest using appropriate encryption and protocols. Ensure effective disposition of data per retention schedules, following service sunset.<br />
* Design systems that: are not susceptible to common security vulnerabilities; are resilient and can be rebuilt quickly in the event of compromise; and fail secure if the system encounters an error or crashes. <br />
* Reduce human intervention and maximize automation of security tasks and processes.<br />
** Integrate and automate security testing to validate code and address vulnerabilities prior to deployments<br />
<br />
<b>Ensure Secure Access to Systems and Services</b><br />
* Identify and authenticate users and devices to an appropriate level of assurance before granting access to information and services.<br />
* Separate and compartmentalize user responsibilities and privileges; assign the least set of privileges necessary to complete the job.<br />
* Constrain service interfaces to authorized entities (users and devices), with clearly defined roles, and only expose the interfaces necessary to operate the service<br />
* Make use of modern credential guidance, and use GC-approved multi-factor authentication where required to stop unauthorized access.<br />
<br />
<b>Maintain Secure Operations</b><br />
* Integrate SA&A activities into security architecture lifecycle processes, to ensure reference artefacts remain relevant and valid. <br />
* Continuously monitor system events and performance in order to detect, prevent, and respond to attacks. <br />
* Design processes to operate services securely, and establish processes and mechanisms to respond effectively to security events.<br />
* Collect transaction logs at infrastructure and application levels to support automated root-cause analysis and performance tuning. <br />
* Include an audit function in information systems. Use a trusted time source and protect audit logs from manipulation.<br />
* Establish processes to monitor security advisories, and apply security-related patches and updates. Apply appropriate risk-based mitigations when patches can’t be applied.<br />
<br><br />
<b> Privacy by Design </b><br />
* Perform a privacy impact assessment (PIA) to support risk mitigation activities when personal information is involved<br />
* Implement security measures to assure the protection of personal information<br />
* Take into consideration the <b>[https://www.ryerson.ca/pbdce/certification/seven-foundational-principles-of-privacy-by-design/ 7 Foundational Privacy Design Principles] </b> when designing services.<br />
</u></I><br />
|}<br />
<br />
<!-- FOOTER -->{| width="100%" cellpadding="10" <br />
<br />
|- valign="top"<br />
| style="color:#3C6D9E;" | <br />
<!-- COLUMN STARTS: --> <br />
<div style="font-size: 1.8em; text-align:center;">Need help? Contact us.</div><br />
<br />
<br />
<br />
<!-- COLUMN 1 STARTS: --> <br />
{| width="100%" cellpadding="5"<br />
<br />
|- valign="top"<br />
| width="33.3%" style="border: 1px solid lightgray; background-color:#fff; color:#409DE2;" | <br />
[[Image: Envelope_icon_blue.png |100px | center]]<br />
<div style="font-size:1.5em; text-align:center; color:white;">{{em|ZZCIOBDP@tbs-sct.gc.ca}}</div><br />
<!-- COLUMN 1 ENDS: --><br />
<br />
<!-- COLUMN 2 STARTS: --> <br />
| width="33.3%" style="border: 1px solid lightgray; background-color:#fff; color:#409DE2;" | <br />
[[Image: gccollab_icon_blue.png |100px | center]]<br />
<div style="font-size:1.5em; text-align:center;">[https://gccollab.ca/groups/profile/1896301/enenterprise-architecture-community-of-practicefrcommunitu00e9-de-pratique-de-architecture-integru00e9e GC Collab]</div><br />
<!-- COLUMN 2 ENDS: --> <br />
<br />
<!-- COLUMN 3 STARTS: --> <br />
| width="33.3%" style="border: 1px solid lightgray; background-color:#fff; color:#409DE2;" | <br />
[[Image: gcconnex_icon_blue.png |100px | center]]<br />
<div style="font-size:1.5em; text-align:center;">[https://gcconnex.gc.ca/groups/profile/7322003/gc-ea-working-group?language=en GCconnex]</div><br />
<!-- COLUMN 3 ENDS: --> <br />
<!-- TABLE ENDS --> |}<br />
<br />
<!-- COLUMN ENDS: --> <br />
<!-- TABLE ENDS --> |}<br />
<!-- end --></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere_-_Web_Server_Configurations&diff=13857GC HTTPS Everywhere - Web Server Configurations2019-11-18T15:52:17Z<p>Tim.allardyce: </p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Communication_Material Communication Material]<br />
|}<br />
<br />
Below are links to example web server configurations for various different platforms and versions. Majority of these were created using the [https://ssl-config.mozilla.org/ Mozilla SSL Configuration Generator]. Configurations are listed in order of age for legacy to modern. <br />
{| class="wikitable"<br />
|+Web Server Configurations<br />
!Platform<br />
!Version<br />
!OpenSSL Version<br />
!Link<br />
|-<br />
|Apache<br />
|2.2.15<br />
|1.1.0<br />
|[[:en:Apache_2.2.15_-_OpenSSL_1.1.0|Click Here!]]<br />
|-<br />
|Lighttpd<br />
|1.4.35<br />
|1.1.1<br />
|[[:en:Lighttpd_1.4.35_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Microsoft IIS 8.5<br />
|Windows Server 2008 R2/2012/2016<br />
|N/A<br />
|[[:en:Microsoft_IIS_8.5_-_WinServer|Cert Install]] & [https://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/ Cipher Order]<br />
|-<br />
|nginx<br />
|1.14.1<br />
|1.1.0<br />
|[[:en:Nginx_1.14.1_-_OpenSSL_1.1.0|Click Here!]]<br />
|-<br />
|AWS ELB<br />
|2014.2.19<br />
|1.1.1<br />
|[[:en:AWS_ELB_2014.2.19|Click Here!]]<br />
|-<br />
|Apache<br />
|2.4.35<br />
|1.0.2g<br />
|[[:en:Apache_2.4.35_-_OpenSSL_1.0.2g|Click Here!]]<br />
|-<br />
|MySQL<br />
|8.0.16<br />
|1.1.1<br />
|[[:en:MySQL_8.0.16_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|nginx<br />
|1.17.0<br />
|1.1.1<br />
|[[:en:Nginx_1.17.0_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Apache<br />
|2.4.39<br />
|1.1.0k<br />
|[[:en:Apache_2.4.39_-_OpenSSL_1.1.0k|Click Here!]]<br />
|-<br />
|Caddy<br />
|0.11.5<br />
|1.1.1<br />
|[[:en:Caddy_0.11.5_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Caddy<br />
|1.0<br />
|1.1.1<br />
|[[:en:Caddy_1.0_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Haproxy<br />
|1.9.8<br />
|1.1.1<br />
|[[:en:Haproxy_1.9.8_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Traefik<br />
|1.7.12<br />
|1.1.1c<br />
|[[:en:Traefik_1.7.12_-_OpenSSL_1.1.1c|Click Here!]]<br />
|}<br />
<br />
<br><br><br />
Questions? Join the conversation on [https://message.gccollab.ca/channel/httpseverywhere-httpspartout GCmessage] (#HTTPSEverywhere-HTTPSpartout) or contact TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca] with any issues/concerns related to HTTPS implementation.</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere_-_Web_Server_Configurations&diff=13856GC HTTPS Everywhere - Web Server Configurations2019-11-18T15:49:52Z<p>Tim.allardyce: </p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Communication_Material Communication Material]<br />
|}<br />
<br />
Below are links to example web server configurations for various different platforms and versions. Majority of these were created using the [https://ssl-config.mozilla.org/ Mozilla SSL Configuration Generator]. Configurations are listed in order of age for legacy to modern. <br />
{| class="wikitable"<br />
|+Web Server Configurations<br />
!Platform<br />
!Version<br />
!OpenSSL Version<br />
!Link<br />
|-<br />
|Apache<br />
|2.2.15<br />
|1.1.0<br />
|[[:en:Apache_2.2.15_-_OpenSSL_1.1.0|Click Here!]]<br />
|-<br />
|Lighttpd<br />
|1.4.35<br />
|1.1.1<br />
|[[:en:Lighttpd_1.4.35_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Microsoft IIS 8.5<br />
|Windows Server 2008 R2/2012/2016<br />
|N/A<br />
|[[:en:Microsoft_IIS_8.5_-_WinServer|Cert Install] & [https://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/ Cipher Order]]<br />
|-<br />
|nginx<br />
|1.14.1<br />
|1.1.0<br />
|[[:en:Nginx_1.14.1_-_OpenSSL_1.1.0|Click Here!]]<br />
|-<br />
|AWS ELB<br />
|2014.2.19<br />
|1.1.1<br />
|[[:en:AWS_ELB_2014.2.19|Click Here!]]<br />
|-<br />
|Apache<br />
|2.4.35<br />
|1.0.2g<br />
|[[:en:Apache_2.4.35_-_OpenSSL_1.0.2g|Click Here!]]<br />
|-<br />
|MySQL<br />
|8.0.16<br />
|1.1.1<br />
|[[:en:MySQL_8.0.16_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|nginx<br />
|1.17.0<br />
|1.1.1<br />
|[[:en:Nginx_1.17.0_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Apache<br />
|2.4.39<br />
|1.1.0k<br />
|[[:en:Apache_2.4.39_-_OpenSSL_1.1.0k|Click Here!]]<br />
|-<br />
|Caddy<br />
|0.11.5<br />
|1.1.1<br />
|[[:en:Caddy_0.11.5_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Caddy<br />
|1.0<br />
|1.1.1<br />
|[[:en:Caddy_1.0_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Haproxy<br />
|1.9.8<br />
|1.1.1<br />
|[[:en:Haproxy_1.9.8_-_OpenSSL_1.1.1|Click Here!]]<br />
|-<br />
|Traefik<br />
|1.7.12<br />
|1.1.1c<br />
|[[:en:Traefik_1.7.12_-_OpenSSL_1.1.1c|Click Here!]]<br />
|}<br />
<br />
<br><br><br />
Questions? Join the conversation on [https://message.gccollab.ca/channel/httpseverywhere-httpspartout GCmessage] (#HTTPSEverywhere-HTTPSpartout) or contact TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca] with any issues/concerns related to HTTPS implementation.</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=13692GC HTTPS Everywhere/Strategy2019-11-14T13:20:44Z<p>Tim.allardyce: </p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments as defined in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-1.html#h-227972 section 2 of the FAA]:'''<br />
<br><br><br />
(a) any of the departments named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-30.html#h-230472 Schedule I];<br><br />
(a.1) any of the divisions or branches of the federal public administration set out in column I of [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-31.html#h-230498 Schedule I.1];<br><br />
(b) a commission under the [https://laws-lois.justice.gc.ca/eng/acts/I-11 Inquiries Act] that is designated by order of the Governor in Council as a department for the purposes of this Act;<br><br />
(c) the staffs of the Senate, House of Commons, Library of Parliament, office of the Senate Ethics Officer, office of the Conflict of Interest and Ethics Commissioner, Parliamentary Protective Service and office of the Parliamentary Budget Officer; and<br><br />
(d) any departmental corporation (a corporation named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-32.html#h-230507 Schedule II]).<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Exemption Requests == <br />
<br />
Departments who cannot implement all the requirements of the ITPIN must apply to GC Enterprise Architecture Review Board (GC EARB) for an exemption with a rationale to justify the request. <br />
Links to the required GC EARB deck template, which includes direction for all departments who will be unable to meet the requirements of the ITPIN by the end of the calendar year, along with an excel template to provide details are below:<br />
<br />
(1.EN) [https://wiki.gccollab.ca/images/6/63/GC_EARB_HTTPS_Exemption.pptx GC EARB HTTPS Exemption Template - EN]<br><br />
(1.FR) [https://wiki.gccollab.ca/images/c/ca/GC_EARB_HTTPS_Exemption_FR.PPTX GC EARB HTTPS Exemption Template - FR]<br><br />
(2.EN) [https://wiki.gccollab.ca/images/0/0a/GC_EARB_HTTPS_Exemption_Details.xlsx GC EARB HTTPS Exemption Details - EN]<br><br />
(2.FR) [https://wiki.gccollab.ca/images/6/6a/GC_EARB_HTTPS_Exemption_Details_FR.xlsx GC EARB HTTPS Exemption Details - FR]<br><br />
<br />
Departments should contact the CIOB-DPPI IT-Division-TI <ZZCIOBDP@tbs-sct.gc.ca> mailbox for further requirements for submitting an exemption request.<br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=File:GC_EARB_HTTPS_Exemption_FR.PPTX&diff=13691File:GC EARB HTTPS Exemption FR.PPTX2019-11-14T12:27:40Z<p>Tim.allardyce: </p>
<hr />
<div></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=File:GC_EARB_HTTPS_Exemption_Details_FR.xlsx&diff=13624File:GC EARB HTTPS Exemption Details FR.xlsx2019-11-08T20:07:52Z<p>Tim.allardyce: GC EARB HTTPS Exemption Details Template - francais</p>
<hr />
<div>== Summary ==<br />
GC EARB HTTPS Exemption Details Template - francais</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=File:GC_EARB_HTTPS_Exemption_Details.xlsx&diff=13623File:GC EARB HTTPS Exemption Details.xlsx2019-11-08T20:07:06Z<p>Tim.allardyce: GC EARB HTTPS Exemption Details Template - english</p>
<hr />
<div>== Summary ==<br />
GC EARB HTTPS Exemption Details Template - english</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=File:GC_EARB_HTTPS_Exemption.pptx&diff=13622File:GC EARB HTTPS Exemption.pptx2019-11-08T20:06:13Z<p>Tim.allardyce: GC EARB HTTPS Exemption Request Template - english</p>
<hr />
<div>== Summary ==<br />
GC EARB HTTPS Exemption Request Template - english</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_HSTS&diff=13533GC HTTPS HSTS2019-11-04T20:01:52Z<p>Tim.allardyce: /* HTTP Strict Transport Security (HSTS) */</p>
<hr />
<div><br />
==HTTP Strict Transport Security (HSTS)==<br />
HSTS is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.<br />
<br><br><br />
HSTS is also highly valuable as an organizational forcing function and compliance mechanism. When a domain owner sets an HSTS policy on its base domain with <code>includeSubDomains</code> and <code>preload</code>, the domain owner is saying '"Every part of our web infrastructure is HTTPS, and always will be."'<br />
<br><br><br />
When a browser knows that a domain has enabled HSTS, it does two things:<br />
* Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.<br />
* Removes the ability for users to click through warnings about invalid certificates<br />
* '''Note:''' HSTS headers set on '''HTTP''' endpoints are '''ignored by most browsers''' due to the potential for malicious headers to be injected, however are recognized on HTTPS endpoints.<br />
<br />
===Types of HSTS===<br />
'''Dynamic HSTS''': Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code><br />
<br><br><br />
This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.<br />
<br><br><br />
'''Static HSTS''': In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention - note the inclusion of preload at the end:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
<br><br><br />
To enable HTTP Strict Transport Security (HSTS) to help the browser secure connections to your service; at least the first of the following two steps should be take, with <code>preload</code> '''only when ready''':<br />
* add the Strict-Transport-Security HTTP header when the site is accessed over HTTPS - this instructs the browser to only request the HTTPS version in future (until the expiration time in the header elapses)<br />
* add your sites to the HSTS preload lists which modern browsers use to automatically redirect HTTP traffic to HTTPS (Chrome’s preload list is included in many of the other browsers’ lists)<br />
<br />
===HSTS Considerations===<br />
When moving to HSTS, bear in mind:<br />
* The policy should be deployed at <nowiki>https://domain.gc.ca</nowiki>, not your HTTP endpoint, nor <nowiki>https://www.domain.gc.ca</nowiki>, added to your .htaccess file.<br />
* In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds: <code>Strict-Transport-Security: max-age=31536000;</code> (1 year)<br />
* In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be “preloaded” into browsers, pre-empting the need to visit via unsecure connection first:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
* All subdomains associated with the parent domain must be fully ready for HTTPS, e.g.: eliminating mixed content. (They do not have to each have their own HSTS policy.)<br />
* When starting with <code>inclSubDomains</code>, it is best to use a very short <code>max-age</code> time (e.g. 5 minutes - 300s) until you are sure your sub-domains are all fully compliant.<br />
<Br><br />
When ready to preload a domain, departments' web teams are recommended to contact their IT Security teams for a review, prior to submitting the domain to the [https://hstspreload.org/ preload list], to ensure it meets the following requirements:<br />
* HTTPS is enabled on the site's root domain (e.g. <nowiki>https://domain.gc.ca</nowiki>), and all subdomains (e.g. <nowiki>https://www.domain.gc.ca</nowiki>) – especially the www subdomain, if a DNS record for it exists. ''This also includes any subdomains in use solely on intranets''.<br />
* The HSTS policy includes all subdomains (<code>inclSubDomains</code>), with a long <code>max-age</code> (at least 1 year = 31536000s), and a header <code>preload</code> flag to indicate that the domain owner consents to preloading.<br />
* The website redirects from HTTP to HTTPS, at least on the site's root domain.<br />
<br><br />
'''Note:''' While preloading a domain is an easy proposition, '''backing out of preloaded status is not a simple task'''; be sure you are ready and want to preload your domain prior to doing so. ''Please ensure you read all of the details [https://hstspreload.org/#removal here] before preloading.'' '''GC.ca will not be preloaded until such time that all subdomain (<nowiki>https://domain.gc.ca</nowiki>) sites are HTTPS and have HSTS enabled.'''<br />
<br><br><br />
Firefox, Safari, Opera, IE11 and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.<br />
<br><br />
<br />
===HSTS Configuration for Common Web Servers===<br />
Departments are encouraged to use the [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla configuration generator] in developing HTST headers, referenced in Section 5, above.<br />
<br><br />
<br />
===HSTS Configuration for WordPress===<br />
For Wordpress, add the header info to the functions.php file. <br />
<br><br />
<br />
===HSTS and Cookies===<br />
When locking in the use of HTTPS through HSTS, cookies should be set with the Secure flag. The scope of the domain and path of the cookies should be set as restrictively as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as cookies often contain session identifiers or other sensitive information.<br />
* Cookie names may be prepended with <code>__Secure-</code> to prevent cookies from being overwritten by insecure sources; <br />
* <code>__Secure-</code> prefix should be used for all cookies sent from secure origins (such as HTTPS). <br />
<br><br />
<br />
===Additional References===<br />
# [https://github.com/cisagov/pshtt#hsts CISAGOV-pshtt (Github)] - fully explains HSTS measurement by domain-scan<br />
# [https://tools.ietf.org/html/rfc6797 HSTS Spec (IETF)]<br />
# [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla Configuration Generator]<br />
# [https://hstspreload.org/ HSTS Preload]<br />
# [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet OWASP HSTS Cheat Sheet]<br />
# [https://www.owasp.org/index.php/SecureFlag OWASP Secure Cookie page]<br />
# [http://caniuse.com/#feat=stricttransportsecurity Browser support for HSTS]<br />
# [https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security HSTS web developer documentation maintained by the Mozilla community]<br />
# [https://scotthelme.co.uk/hsts-cheat-sheet/ HSTS Cheat Sheet (Scott Helme)]</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_HSTS&diff=13532GC HTTPS HSTS2019-11-04T20:01:38Z<p>Tim.allardyce: /* HTTP Strict Transport Security (HSTS) */</p>
<hr />
<div><br />
==HTTP Strict Transport Security (HSTS)==<br />
HSTS is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.<br />
<br><br><br />
HSTS is also highly valuable as an organizational forcing function and compliance mechanism. When a domain owner sets an HSTS policy on its base domain with <code>includeSubDomains</code> and <code>preload</code>, the domain owner is saying '"Every part of our web infrastructure is HTTPS, and always will be."'<br />
<br><br><br />
When a browser knows that a domain has enabled HSTS, it does two things:<br />
* Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.<br />
* Removes the ability for users to click through warnings about invalid certificates<br />
* '''Note:''' HSTS headers set on '''HTTP''' endpoints are ignored by most browsers due to the potential for malicious headers to be injected, however are recognized on HTTPS endpoints.<br />
<br />
===Types of HSTS===<br />
'''Dynamic HSTS''': Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code><br />
<br><br><br />
This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.<br />
<br><br><br />
'''Static HSTS''': In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention - note the inclusion of preload at the end:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
<br><br><br />
To enable HTTP Strict Transport Security (HSTS) to help the browser secure connections to your service; at least the first of the following two steps should be take, with <code>preload</code> '''only when ready''':<br />
* add the Strict-Transport-Security HTTP header when the site is accessed over HTTPS - this instructs the browser to only request the HTTPS version in future (until the expiration time in the header elapses)<br />
* add your sites to the HSTS preload lists which modern browsers use to automatically redirect HTTP traffic to HTTPS (Chrome’s preload list is included in many of the other browsers’ lists)<br />
<br />
===HSTS Considerations===<br />
When moving to HSTS, bear in mind:<br />
* The policy should be deployed at <nowiki>https://domain.gc.ca</nowiki>, not your HTTP endpoint, nor <nowiki>https://www.domain.gc.ca</nowiki>, added to your .htaccess file.<br />
* In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds: <code>Strict-Transport-Security: max-age=31536000;</code> (1 year)<br />
* In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be “preloaded” into browsers, pre-empting the need to visit via unsecure connection first:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
* All subdomains associated with the parent domain must be fully ready for HTTPS, e.g.: eliminating mixed content. (They do not have to each have their own HSTS policy.)<br />
* When starting with <code>inclSubDomains</code>, it is best to use a very short <code>max-age</code> time (e.g. 5 minutes - 300s) until you are sure your sub-domains are all fully compliant.<br />
<Br><br />
When ready to preload a domain, departments' web teams are recommended to contact their IT Security teams for a review, prior to submitting the domain to the [https://hstspreload.org/ preload list], to ensure it meets the following requirements:<br />
* HTTPS is enabled on the site's root domain (e.g. <nowiki>https://domain.gc.ca</nowiki>), and all subdomains (e.g. <nowiki>https://www.domain.gc.ca</nowiki>) – especially the www subdomain, if a DNS record for it exists. ''This also includes any subdomains in use solely on intranets''.<br />
* The HSTS policy includes all subdomains (<code>inclSubDomains</code>), with a long <code>max-age</code> (at least 1 year = 31536000s), and a header <code>preload</code> flag to indicate that the domain owner consents to preloading.<br />
* The website redirects from HTTP to HTTPS, at least on the site's root domain.<br />
<br><br />
'''Note:''' While preloading a domain is an easy proposition, '''backing out of preloaded status is not a simple task'''; be sure you are ready and want to preload your domain prior to doing so. ''Please ensure you read all of the details [https://hstspreload.org/#removal here] before preloading.'' '''GC.ca will not be preloaded until such time that all subdomain (<nowiki>https://domain.gc.ca</nowiki>) sites are HTTPS and have HSTS enabled.'''<br />
<br><br><br />
Firefox, Safari, Opera, IE11 and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.<br />
<br><br />
<br />
===HSTS Configuration for Common Web Servers===<br />
Departments are encouraged to use the [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla configuration generator] in developing HTST headers, referenced in Section 5, above.<br />
<br><br />
<br />
===HSTS Configuration for WordPress===<br />
For Wordpress, add the header info to the functions.php file. <br />
<br><br />
<br />
===HSTS and Cookies===<br />
When locking in the use of HTTPS through HSTS, cookies should be set with the Secure flag. The scope of the domain and path of the cookies should be set as restrictively as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as cookies often contain session identifiers or other sensitive information.<br />
* Cookie names may be prepended with <code>__Secure-</code> to prevent cookies from being overwritten by insecure sources; <br />
* <code>__Secure-</code> prefix should be used for all cookies sent from secure origins (such as HTTPS). <br />
<br><br />
<br />
===Additional References===<br />
# [https://github.com/cisagov/pshtt#hsts CISAGOV-pshtt (Github)] - fully explains HSTS measurement by domain-scan<br />
# [https://tools.ietf.org/html/rfc6797 HSTS Spec (IETF)]<br />
# [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla Configuration Generator]<br />
# [https://hstspreload.org/ HSTS Preload]<br />
# [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet OWASP HSTS Cheat Sheet]<br />
# [https://www.owasp.org/index.php/SecureFlag OWASP Secure Cookie page]<br />
# [http://caniuse.com/#feat=stricttransportsecurity Browser support for HSTS]<br />
# [https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security HSTS web developer documentation maintained by the Mozilla community]<br />
# [https://scotthelme.co.uk/hsts-cheat-sheet/ HSTS Cheat Sheet (Scott Helme)]</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_HSTS&diff=13531GC HTTPS HSTS2019-11-04T19:51:09Z<p>Tim.allardyce: /* HSTS Considerations */</p>
<hr />
<div><br />
==HTTP Strict Transport Security (HSTS)==<br />
HSTS is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.<br />
<br><br><br />
HSTS is also highly valuable as an organizational forcing function and compliance mechanism. When a domain owner sets an HSTS policy on its base domain with <code>includeSubDomains</code> and <code>preload</code>, the domain owner is saying '"Every part of our web infrastructure is HTTPS, and always will be."'<br />
<br><br><br />
When a browser knows that a domain has enabled HSTS, it does two things:<br />
* Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.<br />
* Removes the ability for users to click through warnings about invalid certificates<br />
<br />
===Types of HSTS===<br />
'''Dynamic HSTS''': Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code><br />
<br><br><br />
This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.<br />
<br><br><br />
'''Static HSTS''': In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention - note the inclusion of preload at the end:<br />
<br><br><br />
<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
<br><br><br />
To enable HTTP Strict Transport Security (HSTS) to help the browser secure connections to your service; at least the first of the following two steps should be take, with <code>preload</code> '''only when ready''':<br />
* add the Strict-Transport-Security HTTP header when the site is accessed over HTTPS - this instructs the browser to only request the HTTPS version in future (until the expiration time in the header elapses)<br />
* add your sites to the HSTS preload lists which modern browsers use to automatically redirect HTTP traffic to HTTPS (Chrome’s preload list is included in many of the other browsers’ lists)<br />
<br />
===HSTS Considerations===<br />
When moving to HSTS, bear in mind:<br />
* The policy should be deployed at <nowiki>https://domain.gc.ca</nowiki>, not your HTTP endpoint, nor <nowiki>https://www.domain.gc.ca</nowiki>, added to your .htaccess file.<br />
* In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds: <code>Strict-Transport-Security: max-age=31536000;</code> (1 year)<br />
* In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be “preloaded” into browsers, pre-empting the need to visit via unsecure connection first:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code><br />
* All subdomains associated with the parent domain must be fully ready for HTTPS, e.g.: eliminating mixed content. (They do not have to each have their own HSTS policy.)<br />
* When starting with <code>inclSubDomains</code>, it is best to use a very short <code>max-age</code> time (e.g. 5 minutes - 300s) until you are sure your sub-domains are all fully compliant.<br />
<Br><br />
When ready to preload a domain, departments' web teams are recommended to contact their IT Security teams for a review, prior to submitting the domain to the [https://hstspreload.org/ preload list], to ensure it meets the following requirements:<br />
* HTTPS is enabled on the site's root domain (e.g. <nowiki>https://domain.gc.ca</nowiki>), and all subdomains (e.g. <nowiki>https://www.domain.gc.ca</nowiki>) – especially the www subdomain, if a DNS record for it exists. ''This also includes any subdomains in use solely on intranets''.<br />
* The HSTS policy includes all subdomains (<code>inclSubDomains</code>), with a long <code>max-age</code> (at least 1 year = 31536000s), and a header <code>preload</code> flag to indicate that the domain owner consents to preloading.<br />
* The website redirects from HTTP to HTTPS, at least on the site's root domain.<br />
<br><br />
'''Note:''' While preloading a domain is an easy proposition, '''backing out of preloaded status is not a simple task'''; be sure you are ready and want to preload your domain prior to doing so. ''Please ensure you read all of the details [https://hstspreload.org/#removal here] before preloading.'' '''GC.ca will not be preloaded until such time that all subdomain (<nowiki>https://domain.gc.ca</nowiki>) sites are HTTPS and have HSTS enabled.'''<br />
<br><br><br />
Firefox, Safari, Opera, IE11 and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.<br />
<br><br />
<br />
===HSTS Configuration for Common Web Servers===<br />
Departments are encouraged to use the [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla configuration generator] in developing HTST headers, referenced in Section 5, above.<br />
<br><br />
<br />
===HSTS Configuration for WordPress===<br />
For Wordpress, add the header info to the functions.php file. <br />
<br><br />
<br />
===HSTS and Cookies===<br />
When locking in the use of HTTPS through HSTS, cookies should be set with the Secure flag. The scope of the domain and path of the cookies should be set as restrictively as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as cookies often contain session identifiers or other sensitive information.<br />
* Cookie names may be prepended with <code>__Secure-</code> to prevent cookies from being overwritten by insecure sources; <br />
* <code>__Secure-</code> prefix should be used for all cookies sent from secure origins (such as HTTPS). <br />
<br><br />
<br />
===Additional References===<br />
# [https://github.com/cisagov/pshtt#hsts CISAGOV-pshtt (Github)] - fully explains HSTS measurement by domain-scan<br />
# [https://tools.ietf.org/html/rfc6797 HSTS Spec (IETF)]<br />
# [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla Configuration Generator]<br />
# [https://hstspreload.org/ HSTS Preload]<br />
# [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet OWASP HSTS Cheat Sheet]<br />
# [https://www.owasp.org/index.php/SecureFlag OWASP Secure Cookie page]<br />
# [http://caniuse.com/#feat=stricttransportsecurity Browser support for HSTS]<br />
# [https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security HSTS web developer documentation maintained by the Mozilla community]<br />
# [https://scotthelme.co.uk/hsts-cheat-sheet/ HSTS Cheat Sheet (Scott Helme)]</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12956GC HTTPS Appliances2019-10-08T13:15:51Z<p>Tim.allardyce: /* F5 BIG-IP Specific Support */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Pdf icon.png|75px|left|link=https://wiki.gccollab.ca/images/0/01/Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf]]<br />
<br><br><br><br><br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12955GC HTTPS Appliances2019-10-08T13:13:48Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Pdf icon.png|75px|left|link=https://wiki.gccollab.ca/images/8/89/Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf]]<br />
<br><br><br><br><br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12954GC HTTPS Appliances2019-10-08T13:13:25Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Pdf icon.png|75px|left|link=https://wiki.gccollab.ca/images/8/89/Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf]]<br />
<br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12953GC HTTPS Appliances2019-10-08T13:11:02Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf]]<br><br />
<br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12952GC HTTPS Appliances2019-10-08T13:10:40Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf]]<br><br />
<br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=File:Implementing_ITPIN_2018-01_on_F5_Big-IP_Systems.pdf&diff=12951File:Implementing ITPIN 2018-01 on F5 Big-IP Systems.pdf2019-10-08T13:10:08Z<p>Tim.allardyce: SSC ADC F5 Big IP Systems HTTPS Implementation Guidance</p>
<hr />
<div>== Summary ==<br />
SSC ADC F5 Big IP Systems HTTPS Implementation Guidance</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12950GC HTTPS Appliances2019-10-08T13:09:19Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br><br />
===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
<br><br />
'''New:''' Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Implementing ITPIN 2018-01 on F5 Big-IP Systems.pdf]]<br><br />
<br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Appliances&diff=12949GC HTTPS Appliances2019-10-08T13:08:45Z<p>Tim.allardyce: /* Load Balancing and Reverse Proxies */</p>
<hr />
<div><br />
==Load Balancing and Reverse Proxies==<br />
Load balancers and reverse proxy servers are often implemented with TLS offloading or termination capabilities, and should be included in scope of HTTPS activities. All endpoints should be adequately configured to meet ITPIN requirements. <br />
<br><br><br />
For device specific configuration guidelines, refer to your device manual.<br />
<br===F5 BIG-IP Specific Support===<br />
[[File:F5-fullcolor-lg.jpg|150px|frameless|F5 Networks Logo]]<br><br />
><br><br />
New: Teams managing F5s across the GC are recommended to review the SSC EDC ADC team F5 implementation guidance relevant to ITPIN 2018-01, available here:.<br />
<br><br />
[[File:Implementing ITPIN 2018-01 on F5 Big-IP Systems.pdf]]<br><br />
<br><br />
<u>Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles</u><br><br />
For information about using SSL ciphers with BIG-IP Client SSL (TLS) and Server SSL (TLS) profiles, refer to the articles in tables in the following article:<br><br />
https://support.f5.com/csp/article/K8802<br />
<br><br><br />
<u>Enforce TLS 1.2 HTTPS communications with F5 BIG-IP SSL profiles</u><br><br />
To enforce TLS 1.2 with F5 BIG-IP, use 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. Refer to the following for the detailed step-by-step instructions:<br />
<br><br><br />
<li>https://support.f5.com/csp/article/K17370 (scroll down to section “Configuring the SSL profile to use a specific protocol“)<br />
<li>https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-ssl-administration-12-1-1/4.html (scroll down to section “Assigning SSL profiles to a virtual server”)<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=12000GC HTTPS Web Server Config2019-08-22T17:32:04Z<p>Tim.allardyce: /* Secure configuration advice recommendations */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111. Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (Publication Pending)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
* [https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Transport Layer Security (TLS) best practices with the .NET Framework]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=11999GC HTTPS Web Server Config2019-08-22T17:31:11Z<p>Tim.allardyce: /* Secure configuration advice recommendations */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111. Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
* [https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Transport Layer Security (TLS) best practices with the .NET Framework]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=11769GC HTTPS Everywhere/Strategy2019-08-06T18:42:47Z<p>Tim.allardyce: /* Audience */</p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments as defined in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-1.html#h-227972 section 2 of the FAA]:'''<br />
<br><br><br />
(a) any of the departments named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-30.html#h-230472 Schedule I];<br><br />
(a.1) any of the divisions or branches of the federal public administration set out in column I of [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-31.html#h-230498 Schedule I.1];<br><br />
(b) a commission under the [https://laws-lois.justice.gc.ca/eng/acts/I-11 Inquiries Act] that is designated by order of the Governor in Council as a department for the purposes of this Act;<br><br />
(c) the staffs of the Senate, House of Commons, Library of Parliament, office of the Senate Ethics Officer, office of the Conflict of Interest and Ethics Commissioner, Parliamentary Protective Service and office of the Parliamentary Budget Officer; and<br><br />
(d) any departmental corporation (a corporation named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-32.html#h-230507 Schedule II]).<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=11737GC HTTPS Everywhere/Strategy2019-08-06T12:36:44Z<p>Tim.allardyce: /* Audience */</p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments as defined in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-1.html#h-227972 section 2 of the FAA only]:'''<br />
<br><br><br />
(a) any of the departments named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-30.html#h-230472 Schedule I];<br><br />
(a.1) any of the divisions or branches of the federal public administration set out in column I of [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-31.html#h-230498 Schedule I.1];<br><br />
(b) a commission under the [https://laws-lois.justice.gc.ca/eng/acts/I-11 Inquiries Act] that is designated by order of the Governor in Council as a department for the purposes of this Act;<br><br />
(c) the staffs of the Senate, House of Commons, Library of Parliament, office of the Senate Ethics Officer, office of the Conflict of Interest and Ethics Commissioner, Parliamentary Protective Service and office of the Parliamentary Budget Officer; and<br><br />
(d) any departmental corporation (a corporation named in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-32.html#h-230507 Schedule II]).<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=11736GC HTTPS Everywhere/Strategy2019-08-06T12:33:49Z<p>Tim.allardyce: /* Audience */</p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments as defined in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-1.html#h-227972 section 2 of the FAA only]:'''<br />
<br><br><br />
(a) any of the departments named in Schedule I,<br><br />
(a.1) any of the divisions or branches of the federal public administration set out in column I of Schedule I.1,<br><br />
(b) a commission under the Inquiries Act that is designated by order of the Governor in Council as a department for the purposes of this Act,<br><br />
(c) the staffs of the Senate, House of Commons, Library of Parliament, office of the Senate Ethics Officer, office of the Conflict of Interest and Ethics Commissioner, Parliamentary Protective Service and office of the Parliamentary Budget Officer, and<br><br />
(d) any departmental corporation; (ministère)<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=11735GC HTTPS Everywhere/Strategy2019-08-06T12:33:32Z<p>Tim.allardyce: /* Audience */</p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments as defined in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-1.html#h-227972 section 2 of the FAA only]:'''<br />
<br><br><br />
(a) any of the departments named in Schedule I,<br />
(a.1) any of the divisions or branches of the federal public administration set out in column I of Schedule I.1,<br />
(b) a commission under the Inquiries Act that is designated by order of the Governor in Council as a department for the purposes of this Act,<br />
(c) the staffs of the Senate, House of Commons, Library of Parliament, office of the Senate Ethics Officer, office of the Conflict of Interest and Ethics Commissioner, Parliamentary Protective Service and office of the Parliamentary Budget Officer, and<br />
(d) any departmental corporation; (ministère)<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Strategy&diff=11734GC HTTPS Everywhere/Strategy2019-08-06T12:13:05Z<p>Tim.allardyce: /* Audience */</p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
<br />
{| style="width:1200px;"<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;padding:10px;" scope="col" |<br />
<br />
== Overview == <br />
The Government of Canada (GC)’s [https://www.canada.ca/en/treasury-board-secretariat/topics/information-technology-project-management/information-technology/strategic-plan-information-management-information-technology.html Strategic Plan for Information Management (IM) and Information Technology (IT) 2017-2021] charts the path forward for IM/IT from a whole-of-government or “enterprise” perspective. The Plan details strategic areas of focus (Service, Manage, Secure, and Community) that specify actions and activities that are underway or that represent new enterprise directions. Secure involves, among other things, protective measures to enable the secure processing and sharing of data and information across government. This includes protecting Canadians and their online transactions while interacting with the government. Unencrypted connections to publicly-available GC websites and web services are vulnerable to manipulation, impersonation, and can expose sensitive user information.<br><br><br />
To provide Canadians with the strongest privacy and integrity protection regardless of the sensitivity of the information being transmitted, TBS will establish a “Hypertext Transfer Protocol Secure (HTTPS) everywhere” standard that will require departments and agencies to use the HTTPS protocol for external web-based connections to their services. The HTTPS protocol, along with approved encryption algorithms, will ensure the secure transmission of data online and the delivery of secure web services. <br />
== Purpose ==<br />
This document outlines the considerations and activities for an enterprise-wide implementation of the HTTPS everywhere standard within the GC that will support the provision of secure and reliable web services to Canadians.<br />
== Audience ==<br />
This guide is primarily for business owners, web developers, IT and IT security practitioners who are involved in implementing externally-facing GC online services.<br />
<br />
'''Note: ITPIN 2018-01 [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementing HTTPS for Secure Web Connections] applies to departments in [https://laws-lois.justice.gc.ca/eng/acts/f-11/page-32.html#h-230507 Section 2 of the FAA only].'''<br />
<br />
== Strategy Framework ==<br />
The following table provides an overview of the framework for this strategy.<br />
<br />
{| class="wikitable" border="1" width=1000px;<br />
|- background:#ffffff<br />
! '''Element'''<br />
! '''Description'''<br />
|-<br />
| '''Expected Outcome / Vision'''<br />
| <br />
* Protection of GC online services from manipulation, impersonation, and exposure of sensitive user information<br />
* Increase trust and confidence from Canadians when accessing GC online services<br />
* Consistent protection of the GC network through proportional application of web security controls<br />
|-<br />
| '''Implementation Scope''' <br />
| <br />
* The “HTTPS everywhere” standard is required for all external-facing GC websites within all Departments and Agencies, including future implementation of HSTS.<br />
* All internal-facing GC websites should also enforce HTTPS/HSTS where possible.<br />
|-<br />
| '''Goals'''<br />
| <br />
# Deliver on expectations established in the GC IT Strategic Plan to provide safe and secure access to GC online services.<br />
# Departments and Agencies are supported by Central Agencies and Service Providers throughout their HTTPS everywhere transition.<br />
# All externally-focused GC services with a web-based delivery channel operate via secure (HTTPS) connection only.<br />
# Clear and consistent messaging across all communication platforms to both internal and external stakeholders. <br />
|-<br />
| '''Considerations'''<br />
|<br />
'''Technical Considerations:''' Threat Detection and Encrypted Traffic; Certificate Monitoring; Mixed Content / Compatibility; Automation; Reconfiguring / Reprogramming APIs; HSTS Preloading; and Mobile Traffic.<br />
<br><br><br />
'''Management Considerations:''' Trust in Online Services; Security Return on Investment (ROI); Stakeholder Education; Testing; Costs.<br />
|-<br />
| '''Implementation and Support Requirements''' <br />
| Successful execution of this implementation strategy will require:<br />
* Commitment from Lead Security Agencies (LSA) and supporting IT practitioners and Subject Matter Experts in development of guidance documents in support of GC implementation efforts;<br />
* Mechanisms to provide access to, and effective configuration of infrastructure required to support the Departments’ and Agencies’ implementation of an HTTPS everywhere standard across all external GC websites; <br />
* Effective governance in the development of a GC Certificate Strategy to support HTTPS everywhere implementation;<br />
* Performance measurement and analytics tools to facilitate the tracking and reporting of progress across the GC, and ensure ongoing visibility of the initiative across the management and user community; <br />
* Automation mechanisms to ensure effective and streamlined administration / management of encryption certificates; and <br />
* Formal and informal communications channels to engage internal and external stakeholders.<br />
|}<br />
<br><br><br />
==Suggested Action Plan for ITPIN Compliance==<br />
The following action plan is presented as guidance for project teams undertaking the implementation of HTTPS for a Department or Agency:<br />
<br><br><br />
1. Identify key resources required to act as central point(s) of contact with TBS and the HTTPS Community of Practice. Establish connections via the GCTools channels at:<br />
* GCcollab: [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GC HTTPS Everywhere 2018]<br />
* GCmessage: [https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]<br />
<br><br />
2. Perform an inventory of all departmental domains and subdomains. Sources of information include:<br />
* [https://https-everywhere.canada.ca/ HTTPS Dashboard]<br />
* TBS Application Portfolio Management (APM)<br />
* Departmental business units <br />
<br><br />
3. Provide an up-to-date list of all domain and sub-domains of the publicly-accessible websites and web services to TBS Cybersecurity.<br />
* Update and send the filtered “compliance.csv” file available from the [https://https-everywhere.canada.ca/ HTTPS Dashboard] for mass updates; or<br />
* Use the following website for domain additions: [https://canada-ca.github.io/pages/submit-institutional-domains.html Submit your institution's domains].<br />
<br><br />
4. Perform an assessment of the domains and sub-domains to determine the status of the configuration. Tools available to support this activity include the GC HTTPS Dashboard, [https://www.ssllabs.com/ SSL Labs], [https://www.hardenize.com/ Hardenize], [https://www.sslshopper.com/ssl-checker.html SSLShopper], etc.<br />
<br><br><br />
5. Develop a prioritized implementation schedule for each of the affected websites and web services, following the recommended prioritization approach in the ITPIN:<br />
* ''6.2.1 Newly developed websites and web services must adhere to this ITPIN upon launch.''<br />
* ''6.2.2 Websites and web services that involve an exchange of personal information or other sensitive information must receive priority following a risk-based approach, and migrate as soon as possible.''<br />
* ''6.2.3 All remaining websites and web services must be accessible through a secure connection, as outlined in Section 6.1, by December 31, 2019.''<br />
<br><br />
6. Engage departmental IT planning groups for implementation as appropriate.<br />
* Where necessary adjust IT Plans and budget estimates for the FY where work is expected.<br />
* It is recommended that SSC partners contact their SSC Service Delivery Manager to discuss the departmental action plan and required steps to submit a request for change.<br />
* '''An expedited process for HTTPS BRDs has been established - ensure the title of your BRD is "<u>GC HTTPS Initiative - TLS 1.2 Upgrade</u>", ou également: "<u>Initiative du GC relative à HTTPS – Mise à niveau TLS 1.2</u>"<br />
<br><br />
7. Based on the assessment, and using the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere guidance available on GCcollab], the following activities may be required:<br />
* Obtain certificates from a GC-approved certificate source as outlined in the [https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf Recommendations for TLS Server Certificates] for GC Public Facing Web Services<br />
* Obtain the [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance configuration guidance] for the appropriate endpoints (e.g. web server, network/security appliances, etc.) and implement recommended configurations to support HTTPS.<br />
<br><br />
8. Perform another assessment of the applicable domains and sub-domains to confirm that the configuration has been updated and that all elements are enforced in accordance with [https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]. Results will appear in the [https://https-everywhere.canada.ca/ HTTPS Dashboard] within 24 hours.<br />
<br />
<br><br />
<br />
==Implementation Considerations==<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%"> <br />
'''Click / cliquez:''' <div class="mw-collapsible-content"><br />
{{:GC HTTPS Implementation Considerations}} <br />
</div></div><br />
<br><br />
<br />
== Performance Measurement ==<br />
Measurement of the HTTPS everywhere initiative implementation is essential to ensure program success and lasting security of both GC organizations’ and citizen’s online transactions. Performance of the GC in compliance with the HTTPS everywhere initiative expectations will be measured by the following Key Performance Indicators (KPI): <br />
* Percent of externally-facing GC websites offering HTTPS connections<br />
* Percent of externally-facing GC websites that support HTTP Strict Transport Security<br />
* Percent of externally-facing GC websites that prefer strong symmetric cipher suites (128 bits+)<br />
* Percent of externally-facing GC websites that prefer the use of ephemeral keys (PFS)<br />
<br />
While not mandatory, the following measurement can be applied to internal websites:<br />
* Percent of internally-facing GC websites and web services offering HTTPS connections<br />
<br />
== Compliance Monitoring ==<br />
To monitor compliance to the standard and to measure the KPIs outlined above, the GC will monitor all of its domains for HTTPS support and also monitor how well each domain aligns with HTTPS best practices. The use of public-facing dashboards can help to promote transparency, and identify how well GC organizations are complying with the HTTPS everywhere mandate, in addition to establishing useful alerting and reporting capabilities. The US Government has adopted a similar approach with a publicly accessible dashboard at https://pulse.cio.gov/ [6].<br />
<br />
Furthermore, providing tools to assess website configuration (and vulnerabilities), will help to ensure that GC departments and agencies maintain the security posture of their websites. Examples of implementations include the UK Government’s “WebCheck” [7]. Free tools such as Hardenize’s [8] have also been used by other governments like Sweden which makes its dashboard open to the public.<br />
<br />
This scanning service should help departments and agencies in meeting their obligations to ensure that:<br />
* Data is protected both in transit and when presented in the user's web browser; <br />
* Web site is well engineered and modern technologies are in use to protect it, such as HTTP Strict Transport Security (HSTS) and a Content Security Policy (CSP); <br />
* Records of all certificates in use are maintained in a central inventory, providing access to Certificate Transparency data and clear attribution of chain certificates; and<br />
* Servers and their software are patched. <br />
<br />
The use of continuous, distributed security analytics and infrastructure monitoring will support advanced awareness and automation, thus improving security of both the network and its users. <br />
<br />
== Enquiries ==<br />
Email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=11503GC HTTPS Web Server Config2019-07-31T13:57:36Z<p>Tim.allardyce: /* Additional References */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111. Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 05/31/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
* [https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Transport Layer Security (TLS) best practices with the .NET Framework]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=11311GC HTTPS Web Server Config2019-07-22T17:32:38Z<p>Tim.allardyce: /* Secure configuration advice recommendations */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111. Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 05/31/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Certificate_Guidance&diff=11231GC HTTPS Certificate Guidance2019-07-19T18:19:09Z<p>Tim.allardyce: /* Certificate Recommendations and Guidance */</p>
<hr />
<div><br />
==Certificate Recommendations and Guidance==<br />
<br />
In support of the HTTPS Everywhere initiative, a [[Media:Recommendations for TLS Server Certificates.pdf|recommendations document]] was developed for the purpose of identifying the minimum requirements for TLS server certificate type and content, issuing CA conformance and website responsibilities that apply to all externally facing GC websites. This effort was led by TBS OCIO in close collaboration with members of the HTTPS working group including CRA, CSE, ESDC and SSC. <br />
<br><br><br />
While there are many technical details within the report that are not captured in this brief summary, the most important recommendations are:<br />
<br><br />
* '''Domain Validated (DV) server certificates are recommended''' for use by GC public facing. While the use of Organization Validated (OV) and Extended Validation (EV) certificates is not prevented, DV certificates are preferred due to their lower cost, and ability to support automated certificate issuance, for the same level of security between the web browser and web server as OV/EV certificates. <br />
* The use of the free service provided by '''Let’s Encrypt is recommended for obtaining DV certificates''' combined with the use of [https://letsencrypt.org/docs/client-options/ compatible ACME certificate management agents] (e.g.: https://digital.canada.ca/). <br />
** '''Note:''' This CA should be chosen by an organization who has the ability to manage their certificates, and does not need 3rd party support in the case of an outage. Let’s Encrypt is very much <u>serve yourself</u>. <br />
** Organizations should conduct a thorough assessment of the ACME agent chosen prior to installation, and as updates are made available.<br />
* Organization Validated ('''OV) certificates are not recommended''' for use, as they provide no brand or security benefits above DV certificates.<br />
* If used, '''EV certificates should be obtained from SSC''' (contact [mailto:ssc.ssltls.spc@canada.ca ssc.ssltls.spc@canada.ca]) in order to take advantage of the reduced pricing from an approved CA vendor (Entrust).<br />
{|<br />
|-<br />
| style="width: 500px" align="center" | [[File:Le-logo-twitter.png|250px|link=https://letsencrypt.org/]] [[file:entrust_site_seal_ssl.png|200px|link=mailto:ssc.ssltls.spc@canada.ca]]<br />
|| <br />
| style="width: 500px" align="center" | For additional information, please see [[Media:Recommendations for TLS Server Certificates.pdf|Recommendations for TLS Server Certificates]] for GC Public Facing Web Services or contact TBS-CIOB Cybersecurity ([mailto:zzTBSCybers@tbs-sct.gc.ca zzTBSCybers@tbs-sct.gc.ca])<br />
|}<br />
<br />
===Enterprise Certificate Management===<br />
Recently the National Institute of Standards and Technology released [https://www.nccoe.nist.gov/projects/building-blocks/tls-server-certificate-management Special Publication 1800-16 Securing Web Transactions: TLS Server Certificate Management] for public comment. This draft practice guide provides additional information for enterprises that rely on Transport Layer Security (TLS) to secure both customer-facing and internal applications, so they can better manage TLS server certificates by:<br />
* Defining operational and security policies; identifying roles and responsibilities<br />
* Establishing comprehensive certificate inventories and ownership tracking<br />
* Conducting continuous monitoring of certificate operational and security status<br />
* Automating certificate management to minimize human error and maximize efficiency on a large scale<br />
* Enabling rapid migration to new certificates and keys when cryptographic mechanisms are found to be weak, compromised or vulnerable<br />
<Br><br />
<br />
===Automated Certificate Management Engine (ACME)===<br />
<u>[https://tools.ietf.org/html/rfc8555 RFC 8555: Automatic Certificate Management Environment]</u><br><br />
''Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.'' For details, see the IETF document here: https://tools.ietf.org/html/rfc8555<br />
{|<br />
|-<br />
| style="width: 50%" |<br />
From the Datatracker, published 2019-03-12: https://datatracker.ietf.org/doc/rfc8555/<br />
<br><br><br />
CAs & PKIs that offer ACME certificates (as of April 2019):<br />
# [https://www.buypass.com/ssl/acme Buypass]<br />
# [https://letsencrypt.org Let's Encrypt]<br />
# [https://www.entrustdatacard.com/knowledgebase/how-to-use-acme-to-install-ssl-tls-certificates-in-entrust-certificate-services-apache Entrust (Linux)]<br />
# [https://www.globalsign.com/en-au/auto-enrollment-gateway/ GlobalSign]<br />
# [https://www.venafi.com/ Venafi]<br />
# [https://sectigo.com/resources/sectigos-acme-automation Sectigo (formerly Comodo CA)]<br />
<br><br />
|| <br />
| style="width: 500px" align="center" |[[File:ACME-protocol-icon.png|220px|frameless]]<br />
|}<br />
<br />
===Wildcard Certificates===<br />
It is recognized that wildcard certificates offer several advantages and they may be used where appropriate, however it should be recognized that wildcard certificates may introduce certain risks depending on how they are used.<br />
<br><br />
* Sharing the same private key (certificate) among multiple web servers may introduce additional vulnerabilities that will need to be properly mitigated.<br />
* Compromise through theft of the private key (certificate) would allow an attacker to establish rogue websites that will appear to belong to the domain protected by the wildcard certificate.<br />
* Compromise of the private key renders all TLS sessions protected by that private key vulnerable; the use of a cipher suite supporting [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance#Perfect_Forward_Secrecy_.28PFS.29 Perfect Forward Secrecy] is recommended to avoid this issue.<br />
<br><br />
GC Website owners must ensure appropriate risk mitigation measures are in place to minimize the risk of private key compromise. <br />
* Use of FIPS 140-2 Level 2 or higher Hardware Security Modules is recommended where warranted by risk assessment or cost/benefit trade-off analysis. <br />
* In the absence of HSMs, risk mitigation measures should include effective monitoring and auditing of the system so that private key compromise can be detected as early as possible followed immediately with revocation of the associated server certificate.<br />
<br><br />
Per the [[Media:Recommendations for TLS Server Certificates.pdf|Recommendations for TLS Server Certificates]] [PDF], “care must be exercised when using multi-domain and wildcard certificates to ensure collateral damage is minimized in the event of private key compromise. Copying the same private key to multiple web servers is strongly discouraged unless appropriate risk mitigation measures are in place such as using CSE approved Hardware Security Modules to protect the private key.”<br />
<br><br><br />
Download the Recommendations for TLS Server Certificates.pdf: <br />
[[File:Pdf icon.png|75px|left|link=https://wiki.gccollab.ca/images/8/89/Recommendations_for_TLS_Server_Certificates.pdf]]<br />
<br><br><br><br><br><br />
<br />
===HTTP Public Key Pinning (HPKP)===<br />
HPKP has been deprecated, as of end of 2017. <br />
<br><br><br />
To defend against certificate misissuance, web developers should use '''Certificate Authority Authorization (CAA)''' and the <code>Expect-CT</code> header, including its reporting function. <code>Expect-CT</code> is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs.<br />
<br><br><br />
Implementation of the Expect-CT header can be undertaken as follows, with a 1 year expiry: <code>http request Expect-CT: enforce, max-age=31536000, report-uri="https://example.com"</code><br />
<br><br><br />
'''Note:''' caution should be taken in implementing the <code>Expect-CT</code> header, as there is a risk of rendering your site unreachable if done wrong. In testing, it is recommended to deploy the header without the <code>enforce</code> element, and a <code>max-age</code> of 0 (zero). This arrangement will ensure that you don't block any connections with a bad certificate, however do send an error to the report-uri address (e.g.: email mailbox for simplicity's sake, or a script to handle the error and log/notify as required if desired). After testing for a period of time to provide assurance that everything still works as expected, you are able to enable the <code>enforce</code> directive, and increase the <code>max-age</code> (recommended to be 1 year - 31536000).<br />
<br><br><br />
Prior to enforcing Expect-CT, be sure that your CA uses the CT logs (as they should, per certificate recommendations).<br />
<br><br><br />
Set up for '''CAA''' is performed in the DNS record, explicitly naming which CA(s) are allowed to issue certificates for your website. SSL Mate has developed a very helpful tool to assist in the development of DNS entries for CAA, available [https://sslmate.com/caa/ here].<br />
<br><br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11126HTTPS Speaking Points2019-07-18T15:28:27Z<p>Tim.allardyce: /* What Departments Need to do to be Compliant */</p>
<hr />
<div><br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g.: Entrust via SSC; see Certificates in [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance] for more).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11125HTTPS Speaking Points2019-07-18T15:26:11Z<p>Tim.allardyce: </p>
<hr />
<div><br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g. Entrust via SSC).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11124HTTPS Speaking Points2019-07-18T15:25:33Z<p>Tim.allardyce: </p>
<hr />
<div><br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===Current Status===<br />
* TBS is tracking compliance and will soon launch the [https://https-everywhere.canada.ca/en/index/ compliance dashboard] publicly. The compliance dashboard has been available to departments to track their compliance since August 2018.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g. Entrust via SSC).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11123HTTPS Speaking Points2019-07-18T15:23:43Z<p>Tim.allardyce: </p>
<hr />
<div>'==Speaking Points for Implementing HTTPS==<br />
<br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===Current Status===<br />
* TBS is tracking compliance and will soon launch the [https://https-everywhere.canada.ca/en/index/ compliance dashboard] publicly. The compliance dashboard has been available to departments to track their compliance since August 2018.<br />
* Compliance rates remain low (24%) due to a number of factors including an outdated list of GC domains. TBS sent an email communique to all departments in January 2019 requesting departments validate their domain names; only 61% of departments have confirmed validation, which means that the remaining 39% of departments may have inaccurate data in the dashboard. It is important that all departments and agencies validate their domain list. Please see Annex A for a list of departments that have not validated their domain names.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g. Entrust via SSC).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11122HTTPS Speaking Points2019-07-18T15:23:19Z<p>Tim.allardyce: </p>
<hr />
<div><br />
==Speaking Points for Implementing HTTPS==<br />
<br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===Current Status===<br />
* TBS is tracking compliance and will soon launch the [https://https-everywhere.canada.ca/en/index/ compliance dashboard] publicly. The compliance dashboard has been available to departments to track their compliance since August 2018.<br />
* Compliance rates remain low (24%) due to a number of factors including an outdated list of GC domains. TBS sent an email communique to all departments in January 2019 requesting departments validate their domain names; only 61% of departments have confirmed validation, which means that the remaining 39% of departments may have inaccurate data in the dashboard. It is important that all departments and agencies validate their domain list. Please see Annex A for a list of departments that have not validated their domain names.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g. Entrust via SSC).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=HTTPS_Speaking_Points&diff=11121HTTPS Speaking Points2019-07-18T15:22:44Z<p>Tim.allardyce: Created page with "==Speaking Points for Implementing HTTPS== ===What is HTTPS?=== * The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol de..."</p>
<hr />
<div>==Speaking Points for Implementing HTTPS==<br />
<br />
===What is HTTPS?===<br />
* The Hypertext Transfer Protocol (HTTP) is the foundation for data communication on the web. This protocol defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. <br />
* Hypertext Transfer Protocol Secure (HTTPS) combines HTTP with a security layer to protect user connections to websites. HTTPS guarantees the protection of the connection between two systems. It will not protect the system itself from being hacked or its information from being breached.<br />
<br />
===Background===<br />
* In June 2018, TBS issued an Information Technology Policy [https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html Implementation Notice (ITPIN) on Implementing Hypertext Transfer Protocol Secure (HTTPS) for Secure Web Connections] on all publicly accessible websites and web services. The original compliance deadline was September 30, 2019; however, the deadline was recently extended to December 31, 2019. The extended deadline has been communicated to departments.<br />
<br />
===Current Status===<br />
* TBS is tracking compliance and will soon launch the [https://https-everywhere.canada.ca/en/index/ compliance dashboard] publicly. The compliance dashboard has been available to departments to track their compliance since August 2018.<br />
* Compliance rates remain low (24%) due to a number of factors including an outdated list of GC domains. TBS sent an email communique to all departments in January 2019 requesting departments validate their domain names; only 61% of departments have confirmed validation, which means that the remaining 39% of departments may have inaccurate data in the dashboard. It is important that all departments and agencies validate their domain list. Please see Annex A for a list of departments that have not validated their domain names.<br />
<br />
===What Should Communications Teams do?===<br />
* Section 6.2.1 of the ITPIN states that newly developed websites and web services must adhere to the ITPIN upon launch. Therefore, communications teams should include this requirement as part of the web publication process to ensure that new websites and web services are not published using unsecure connections. <br />
* Section 6.2.2 of the ITPIN states that websites and web services that involve an exchange of personal information or other sensitive information must receive priority and migrate as soon as possible. Therefore, communications teams should identify these websites and develop a schedule for immediate migration to HTTPS<br />
* Section 6.2.3 of the ITPIN states that all remaining websites and web services must be accessible through a secure connection by December 31, 2019. Therefore, communications teams should ensure that existing sites are being migrated leading up to the compliance deadline. For example, communications teams could ensure that when new content is published to existing sites, HTTPS is implemented at the same time to avoid the risk of new content being released on unsecured websites. <br />
<br />
===How to Increase Compliance===<br />
* To assist departments in meeting the requirements in the Policy Implementation Notice, TBS has provided departments with the following implementation guidance documents and tools:<br />
** [https://https-everywhere.canada.ca/en/guidance/ Project guidance]<br />
** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere HTTPS Everywhere on GCcollab] wiki including:<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance Implementation Guidance]<br />
*** [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Strategy Implementation Strategy]<br />
** [https://gcconnex.gc.ca/groups/profile/35218846/gc-https-everywhere-2018-https-partout-dans-le-gc-2018 HTTPS Everywhere on GCconnex] and [https://gccollab.ca/groups/profile/1358152/engc-https-everywhere-2018frgc-https-partout-2018 GCcollab]<br />
*** Regular blog posts <br />
** [https://message.gccollab.ca/channel/httpseverywhere-httpspartout HTTPS Everywhere on GCmessage]<br />
* TBS has been running bi-weekly workshops since January 2019 to share information and provide technical guidance. TBS will continue to run monthly workshops until December 2019. We encourage departments to send their staff. <br />
* TBS is continuing to work one-on-one with departments and agencies to address challenges to improve overall compliance to the ITPIN. If departments are facing challenges, they should contact the TBS Cyber Security Division ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]).<br />
<br />
===What Departments Need to do to be Compliant===<br />
* Departments must validate the list of domains on the compliance dashboard, <br />
**Contact the TBS Cyber Security mailbox with changes, as required ([mailto:zzTBScybers@tbs-sct.gc.ca zzTBScybers@tbs-sct.gc.ca]) <br />
* If the department is one of the 43 departments that are Shared Services Canada partners, the department should contact their account executive and service delivery manager to initiate planning and implementation of HTTPS. <br />
* Public domains must be configured to redirect users immediately to an HTTPS connection, after which they may then be redirected to pages on subsequent domains (e.g. Canada.ca).<br />
* Public domains must provide instructions for users’ browsers to only connect to the HTTPS domains (i.e. HTTP Strict Transport Security (HSTS) must be enabled).<br />
* Public domains must disable known weak connection protocols and encryption ciphers, in accordance Communication Security Establishment guidance (ITSP.40.062 and ITSP.40.111).<br />
* Public domains must use HTTPS certificates issued from a Certificate Authority (e.g. Entrust via SSC).</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Everywhere/Communication_Material&diff=11103GC HTTPS Everywhere/Communication Material2019-07-18T13:14:53Z<p>Tim.allardyce: </p>
<hr />
<div>[[File:GCcollab Banner http-vs-https skinny.png|1200px|top|left|link=GC_HTTPS_Everywhere|GC HTTPSEverywhere]]<br />
<br />
{| class="wikitable" style="align:center; border-top: #000000 2px solid; border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1200px"<br />
|-<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[https://www.canada.ca/en/government/system/digital-government/modern-emerging-technologies/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html ITPIN 2018-01]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Strategy | Implementation Strategy]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Implementation Guidance | Implementation Guidance]]<br />
! style="background: #dddddd; color: black" width="250px" scope="col" |[[../Communication Material | Communication Material]]<br />
|}<br />
<br />
{| style="width:1200px;"<br />
|-<br />
|{{TOCleft}}<br />
|-<br />
| style="backgound:#ffffff;width:900px;text-align:left;weight:normal;" scope="col" |<br />
== Communication Plan ==<br />
Regular and consistent communication across the diverse stakeholder community will be important in achieving HTTPS everywhere compliance within each GC organization. A clear communications strategy will also reduce the likelihood of stakeholder resistance to an HTTPS everywhere migration.<br />
<br />
The following proposes the essential communications actions required for successful implementation of GC HTTPS:<br />
# Utilize both formal and informal communications channels as conduits for information flow.<br />
# Establish a brand to be used in project planning and execution, to provide a common anchor for communications and conversation with stakeholders, industry and citizens. <br />
# Establish clear communication channels throughout the GC for senior leadership as champions of the HTTPS everywhere initiative.<br />
# Develop technical guidance / briefing material in the form of an ITPIN for CIOs and IT teams across the GC outlining expectations and timelines.<br />
# Coordinate with service owners to establish media lines to announce the change to GC websites and services, informing citizens of the impact and future requirements.<br />
# Utilize GC Tools and public social media platforms to establish a forum for Q&A discussion with service and technology owners, and industry specialists.<br />
# Develop guidance / briefing material for business owners across the GC with respect to the importance of the changes and expected impact on their services.<br />
# Develop effective strategies to engage with remote teams across the GC (both governance and information sharing).<br />
<br />
<br><br />
<div class="toccolours mw-collapsible mw-collapsed" style="font-size:14pt; width:100%"> <br />
'''HTTPS Speaking Points''' <div class="mw-collapsible-content" style="font-size:11pt;"><br />
---- {{:HTTPS Speaking Points}} </div></div><br />
<br><br />
<br />
==Q&A Scenarios==<br />
<br />
This material is provided as a starting point for discussions with business and technical partners depending on the scenario/context presented. If there are other areas that need to be covered, please contact TBS via the mailbox (below) or engage in the chat on GCmessage ([https://message.gccollab.ca/channel/httpseverywhere-httpspartout #HTTPSEverywhere-HTTPSpartout]).<br />
<br />
===My Site Is Only Accessible Internally===<br />
The HTTPS ITPIN is only applicable to externally focused public websites and web services. Your site is out of scope of this direction, however you are still recommended to consider implementing HTTPS.<br />
<br />
===Can I Still Serve My Site Over HTTP If I Also Have HTTPS?===<br />
No, all publicly available websites should only offer HTTPS connections by September 30, 2019. Any HTTP connections should be permanently redirected to the HTTPS website.<br />
<br />
===My Website Works Just Fine Over HTTP===<br />
Not anymore. As of July 2018, Google Chrome will begin alerting all HTTP connections as Not Secure, with other major browsers potentially following suit. This issue presents a new reputational risk to digital services. <br />
<br />
===No Forms or Information Collected===<br />
HTTPS protects more than just form data. HTTPS keeps the URLs, headers, and contents of all transferred pages confidential.<br />
<br />
===There is Nothing Sensitive on My Site===<br />
Cyberspace is borderless, and HTTP connections are simply a liability. Just as we have no control over detours on surface roads, we have no control over the route traffic will take through the internet. <br />
<br><br>This lack of control introduces opportunities to inject text, scripts, images, or ad content onto your page so that it looks like you put them there. HTTPS prevents this activity, and guarantees content integrity and the ability to detect tampering. <br />
<br><br>Additionally, if we encrypt only sensitive content, then we automatically paint a target on that content. Keep your secrets secret by encrypting everything.<br />
<br />
===HTTPS Is Going To Slow Down My Website – Encryption Is CPU Intensive===<br />
No it's not. Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2. Over 75% of the world’s websites are now HTTPS, including the largest banks, social media sites. <br />
<br><br>Latency metrics provided by them over time have proven that properly implemented HTTPS is faster than HTTP. https://istlsfastyet.com/ <br />
<br />
===My Site Is HTTP, But Our Forms Are Submitted Over HTTPS===<br />
A site using HTTP is susceptible to interception and manipulation, meaning you lose control over the actions associated with the forms you present to your users, regardless of how they’re submitted. <br />
<br><br>Attackers are provided the chance to modify how/where the data is submitted, and there's no way to detect this because it happens over the wire with plain HTTP. <br />
<br><br>Encrypting your whole site with HTTPS from the start prevents this.<br />
<br />
===Certificates Are Expensive - I Don’t Have The Budget This Year.===<br />
They're free. (Let’s Encrypt)<br />
<br />
===I Don’t Have The Skillsets Or Resources To Support HTTPS===<br />
HTTPS doesn’t have to be complicated; many web servers such as Caddy are designed to be run natively with HTTPS as default now, and server configuration generators are available from organizations like Mozilla. Certificate management has been made exponentially easier with the introduction of automation for renewals. <br />
<br />
===My Site Can Still Be Impersonated, Even If I Use HTTPS===<br />
The dangers presented by impersonation online are greatly mitigated by the use of HTTPS and a properly issued certificate (one logged in certificate transparency (CT) logs, with a strong signature algorithm (at least SHA-256), from an authorized CA (CAA)). <br />
<br><br>As long as your server is secured, and your private key remains private, any mismatched certificate will be flagged by browsers as such, or invalid, resulting in a Not Secure alert to the user. Internal processes reviewing CT logs for mis-issued certs will catch illegitimate certificates. <br />
<br><br>Finally, if the impersonator doesn’t use HTTPS at all, browsers will alert the malicious site as insecure immediately.<br />
<br />
===Domain-Validated (DV) Certificates Aren't Secure===<br />
Domain Validated certificates offer the same technical security as Extended Validation (EV) certificates, and it has been shown increasingly that the promised value of EV certs has not been realized. <br />
<br><br>As long as you don’t lose control of your DNS entries or domain hosting, and choose a competent certificate authority, DV certs are perfectly acceptable. There is absolutely no difference in the cryptography in a DV certificate compared to that of an extended validation (EV) certificate.<br />
<br />
===What If A Certificate Authority Misissues A Cert For My Site?===<br />
The GC is working to establish governance around the issuance of certificates through the use of CAA records to restrict which CAs can issue certificates for website. Until that time, the system will rely on certificate transparency and oversight to manage the infrastructure.<br />
<br />
===Phishing Sites Use HTTPS===<br />
<br>Yes, they do, but this isn’t a good reason not to use HTTPS.<br />
<br />
===Our Site Relies Heavily On 3rd Party Content Over HTTP===<br />
The inclusion of HTTP content from a 3rd party provider is a proven vector for attack, as you do not have control over the security of that content. Moving to HTTPS means any content included in your website should be from HTTPS-enabled sources, to avoid both mixed-content errors and the inherent vulnerabilities it presents. <br />
<br><br>As this may require renegotiation or termination of contracts with content providers, it is recommended to begin sooner rather than later, or convince your content providers to move to HTTPS as well. <br />
<br />
===HTTPS Impacts Search Engine Optimization===<br />
HTTPS improves SEO! <br />
<br><br>It is true that switching and redirecting site URLs incorrectly may impact your search rankings, but overall HTTPS has been taken into consideration to actually improve rankings. <br />
<br><br>Ensure you follow the guidance of the search engine you're optimizing for, and everything will be fine.<br />
<br><br><br />
''Adapted from: https://doesmysiteneedhttps.com/''<br />
<br />
== Enquiries ==<br />
Feel free to join the conversation on [https://message.gccollab.ca/channel/httpseverywhere-httpspartout GCmessage] (#HTTPSEverywhere-HTTPSpartout), or email your questions to TBS Cyber Security at [mailto:ZZTBSCYBERS@tbs-sct.gc.ca ZZTBSCYBERS@tbs-sct.gc.ca].<br />
<br />
<br /><br />
|}</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=10979GC HTTPS Web Server Config2019-07-16T15:23:09Z<p>Tim.allardyce: /* Secure configuration advice recommendations */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111. Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 09/01/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=10954GC HTTPS Web Server Config2019-07-16T12:51:12Z<p>Tim.allardyce: /* Secure configuration advice recommendations */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers which satisfy the cryptographic guidance provided in ITSP.40.111. It is recommended that servers be configured to exclusively support the cipher suites listed in the second column, preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 09/01/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Exception Use Only) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=10953GC HTTPS Web Server Config2019-07-16T11:53:36Z<p>Tim.allardyce: /* TLS Cipher Suite Support */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers which satisfy the cryptographic guidance provided in ITSP.40.111. It is recommended that servers be configured to exclusively support the cipher suites listed in the second column, preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 09/01/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Only By Exception) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&diff=10952GC HTTPS Web Server Config2019-07-16T11:53:06Z<p>Tim.allardyce: /* TLS Cipher Suite Support */</p>
<hr />
<div><br />
==Recommendations==<br />
Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist. <br />
<br />
A broad overview of the use of TLS is provided in the draft NIST [https://csrc.nist.gov/publications/detail/sp/1800-16/draft Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT))]. Detailed TLS configuration guidance for both servers and clients is similarly provided in [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]. Note that [https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft NIST SP 800-52 Rev 2 draft] is available for review, but has yet to be formally published.<br />
<br />
Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:<br />
* [https://mozilla.github.io/server-side-tls/ssl-config-generator/ Mozilla SSL Config Generator]<br />
* [https://www.ssllabs.com/ssltest/ SSL Labs SSL Test]<br />
<br />
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)<br />
<br><br><br />
<br />
==Redirect Domains==<br />
Many 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). When a specific domain directs users to another domain, they are considered redirect domains.<br />
<br><br><br />
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP. 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.<br />
<br><br><br />
For each of the redirected URLs, configuration should: <br />
<br />
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then<br />
# 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))<br />
<br />
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one. If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.<br />
<br><br><br />
'''Note:''' when redirecting to Canada.ca, or another major GC platform 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. Each domain must be configured appropriately to reach full compliance.<br />
<br><br><br />
Additional References:<br />
# [https://www.htaccessredirect.net .htaccess Generator]<br />
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan<br />
<br><br />
<br />
==TLS Cipher Suite Support==<br />
Departments should make use of CSE-approved cryptographic algorithms, as outlined in:<br />
* CSE’s ITSP.40.111 [https://www.cse-cst.gc.ca/en/publication/list/Cryptography Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information]<br />
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.<br />
<br><br />
===About Cipher Suites===<br />
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use. If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.<br />
<br><br><br />
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code><br />
<br><br><br />
The meaning of this name is:<br />
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.<br />
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.<br />
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.<br />
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.<br />
<br />
===Secure configuration advice recommendations===<br />
In general, when configuring servers:<br />
* Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates. <br />
* Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.<br />
* Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.<br />
<br><br />
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].<br />
<br><br><br />
In the following table, the first column lists all ciphers which satisfy the cryptographic guidance provided in ITSP.40.111. It is recommended that servers be configured to exclusively support the cipher suites listed in the second column, preferring them in the listed order:<br />
{| class="wikitable" border="1" <br />
|-<br />
! Full ITSP.40.111 Cipher Suites<br />
! Modified ITSP 40.111 Cipher Suites<br />
! Target Cipher Suites (<span style="color:red;">NEW:</span> 09/01/19)<br />
|- style="vertical-align:top;"<br />
| <br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)<br />
* TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and<br />
* TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)<br />
<br />
|<br />
<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;<br />
* TLS_DHE_RSA_WITH_AES_128_CCM;<br />
* TLS_DHE_RSA_WITH_AES_256_CCM;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;<br />
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)<br />
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)<br />
* TLS_RSA_WITH_AES_128_GCM_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_GCM_SHA384; (2)<br />
* TLS_RSA_WITH_AES_128_CCM; (2)<br />
* TLS_RSA_WITH_AES_256_CCM; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA256; (2)<br />
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)<br />
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
* TLS_AES_128_CCM_8_SHA256 (5)<br />
<br />
|<br />
<br />
Recommended and prioritized (TLS 1.3):<br />
* TLS_AES_256_GCM_SHA384 (5)<br />
* TLS_AES_128_GCM_SHA256 (5)<br />
* TLS_AES_128_CCM_SHA256 (5)<br />
<br />
Recommended and prioritized (TLS 1.2):<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM<br />
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br />
Sufficient (Use Only By Exception) and prioritized (TLS 1.2):<br />
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)<br />
* TLS_DHE_RSA_WITH_AES_256_CCM (6)<br />
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CCM (6)<br />
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br />
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)<br />
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)<br />
<br />
|}<br />
<br />
<br><br />
''Notes:''<br />
* (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.<br />
* (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.<br />
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.<br />
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]<br />
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.<br />
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.<br />
<br><br />
<br />
===Perfect Forward Secrecy (PFS)===<br />
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.<br />
<br />
Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:<br />
* CSE’S [https://www.cse-cst.gc.ca/en/publication/list/Security-Protocols Guidance on Securely Configuring Network Protocols]<br />
<br />
''Note:'' TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.<br />
* The [https://https-everywhere.canada.ca/ GC HTTPS dashboard] for all external domains will note when a domain offers little or no forward secrecy.<br />
* ''[https://www.ssllabs.com/ssltest/analyze.html?d=cyber.gc.ca&s=205.193.218.119&hideResults=on cyber.gc.ca]'' is configured to offer robust forward secrecy.<br />
<br />
<br><br />
<br />
===HTTP/2===<br />
HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.<br />
<br />
HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.<br />
<br />
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.<br />
<br />
This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.<br />
* [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]<br />
* [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec<br />
<br><br />
<br />
===TLS 1.3===<br />
''Note:'' the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points. <br />
<br><br><br />
Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.<br />
<br><br><br />
TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref><br />
<br /><br />
* The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.<br />
* A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in [https://tools.ietf.org/html/rfc8446 RFC 8446 Appendix E.5].<br />
* Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.<br />
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.<br />
* The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.<br />
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.<br />
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation. <br />
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK <br />
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).<br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Supported Groups !! RFC Reference<br />
|-<br />
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp384r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| secp521r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]<br />
|-<br />
| ffdhe2048 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe3072 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe4096 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe6144 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|-<br />
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]<br />
|}<br />
<br /><br />
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:<br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference<br />
|-<br />
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]<br />
|-<br />
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446] <br />
|-<br />
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|-<br />
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]<br />
|}<br />
<br /><br />
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.<br />
<br /><br /><br />
<br />
<br />
===Testing===<br />
Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:<br />
* [https://www.ssllabs.com/ssltest/ Qualys SSL Server Test]<br />
* [https://www.hardenize.com/ Hardenize domain analysis tool]<br />
<br />
These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.<br />
<br />
<br><br />
===Search Engine Optimization (SEO)===<br />
In general, migrating to HTTPS improves a website’s own SEO and analytics.<br />
* As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.<br />
* Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.<br />
Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:<br />
* If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.<br />
* Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <code><link rel="canonical" href="https://example.gc.ca/folder/folder2/"></code><br />
<br />
<br><br />
===Additional References===<br />
There are a number of good guides that provide configuration advice for HTTPS:<br />
* [https://www.ssllabs.com/projects/best-practices/index.html Qualys - SSL/TLS Deployment Best Practices]<br />
* [https://support.google.com/webmasters/answer/6073543 Google - Webmasters: Secure Your Site with HTTPS]<br />
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]<br />
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]<br />
<br />
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.<br />
<br />
<br></div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Cyber-security&diff=9702Cyber-security2019-06-09T21:42:29Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Gc-cyber&diff=9701Gc-cyber2019-06-09T21:41:55Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Gccyber&diff=9700Gccyber2019-06-09T21:41:36Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Itsecurity&diff=9699Itsecurity2019-06-09T21:40:49Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=ITS&diff=9698ITS2019-06-09T21:40:24Z<p>Tim.allardyce: Created page with "Redirect Cyber"</p>
<hr />
<div>Redirect Cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=ITSecurity&diff=9697ITSecurity2019-06-09T21:40:05Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=IT-Security&diff=9696IT-Security2019-06-09T21:39:48Z<p>Tim.allardyce: Created page with "Redirect cyber"</p>
<hr />
<div>Redirect cyber</div>Tim.allardycehttps://wiki.gccollab.ca/index.php?title=Cybersecurity&diff=9695Cybersecurity2019-06-09T21:39:22Z<p>Tim.allardyce: Created page with "Redirect GC HTTPS"</p>
<hr />
<div>Redirect GC HTTPS</div>Tim.allardyce