This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
**[REQ-TLS-SBD-1]**: The web browser shall be configured by default to reject TLS protocol versions, cipers and configurations which present high risk to exploitation.
**[REQ-TLS-SBD-1]**: The product shall be configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.
Editor's note: Consider whether "high risk to exploitation" is an appropriate phrase, and whether this requirement should say "reject or warn" instead of "reject". See also REQ-TLS-CON-3.
<mark>Editor's note: "high risk to exploitation" is ok to say? and should we say "reject or warn" instead of "reject". See also REQ-TLS-CON-3.</mark>
<mark>Editor's note: This requirement might be implied by Annex K. TODO: Research this interpretation and delete if redundant.</mark>
**[REQ-TLS-SBD-2]**: The web browser shall be configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.
**[REQ-TLS-SBD-2]**: The product shall be configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.
Applicability: Web browsers which maintain their own root store, rather than using the OS's root store.
@@ -468,7 +468,7 @@ Proposed ESR code: SU
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).
**[REQ-TLS-SU-1]**: The web browser's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.
**[REQ-TLS-SU-1]**: The product's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.
Applicability: Web browsers which maintain their own root store, rather than using the OS's root store.
@@ -526,19 +526,19 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography
**[REQ-TLS-CON-1]**: The web browser shall support TLS versions and configurations indicated as "recommended" (R) of the ENISA Agreed Cryptographic Methods [1], and it may support TLS versions and configurations indicated as "legacy" (L).
**[REQ-TLS-CON-1]**: The product shall support TLS versions and configurations indicated as "recommended" (R) of the ENISA Agreed Cryptographic Methods [1], and it may support TLS versions and configurations indicated as "legacy" (L).
Note: These algorithms are listed on page 37-38 of [1](https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en?filename=ECCG%20Agreed%20Cryptographic%20Mechanisms%20version%202.pdf). TLS 1.3 [i.7] is R, and TLS 1.2 [i.6] is L. The L[2025] algorithms (with CBC) are not considered state of the art, and should be ignored.
<mark>Editor's note: This requirement might be implied by Annex K. TODO: Research this interpretation and delete if redundant.</mark>
**[REQ-TLS-CON-2]**: The web browser shall check the full validity of certificate chain through to the root, including for expiration and revocation.
**[REQ-TLS-CON-2]**: The product shall check the full validity of certificate chain through to the root, including for expiration and revocation.
**[REQ-TLS-CON-3]**: The web browser shall warn or obstruct the user from interacting with with content served over insecure connections, including expired certificates and insecure TLS configurations.
**[REQ-TLS-CON-3]**: The product shall warn or obstruct the user from interacting with content served over insecure connections, including expired certificates and insecure TLS configurations.
Example: When presenting content served with cryptographic methods with a certain risk of exploitation, a web browser presents a user with a user interface element representing a broken lock, or an interstitial requiring user interaction to proceed.
**[REQ-TLS-CON-4]**: The web browser shall implement appropriate technologies to promote or require the use of HTTPS rather than HTTP.
**[REQ-TLS-CON-4]**: The product shall implement appropriate technologies to promote or require the use of HTTPS rather than HTTP.
Example: Implementation of HSTS [i.8], active mixed content blocking [i.9], and HTTPS-First loading strategies.
@@ -674,7 +674,7 @@ Proposed ESR code: LOG
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).
**[REQ-TLS-LOG-1]**: The web browser shall present a user interface giving visibility into the security properties of the connection, including the origin.
**[REQ-TLS-LOG-1]**: The product shall present a user interface giving visibility into the security properties of the connection, including the origin.
**[REQ-EXT-LOG-1]**: The product shall provide the user the ability to identify which user-installed extensions are currently running, and the permissions in effect for each.
@@ -685,7 +685,7 @@ Proposed ESR code: DRT
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (m).
**[REQ-TLS-DRT-1]**: The web browser shall make available functionality to reset TLS-related functionality to the initial safe settings, including selection of algorithms and protocol versions, root certificates, and any other relevant properties.
**[REQ-TLS-DRT-1]**: The product shall make available functionality to reset TLS-related functionality to the initial safe settings, including selection of algorithms and protocol versions, root certificates, and any other relevant properties.
Applicability: Web browsers which allow changing TLS-related settings.
@@ -795,6 +795,61 @@ Proposed ESR code: KEV
Proposed ESR code SBD
### [ACC-TLS-SBD-1]
Assessment of [REQ-TLS-SBD-1]
**Assessment Reference:** The product shall be configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.
**Assessment Objective:** The product is configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Configure a web server to expose websites served with several protocol versions, ciphers or configurations which present a high risk to exploitation.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to each website and observe how it loads.
**Assignment of Verdict:**
-**Pass**: Each navigation attempt to the vulnerable website is blocked by the product.
-**Fail**: Any of the above are not fulfilled.
**Supporting Evidence:**
- Logs or screenshots showing the product's response to the navigation.
### [ACC-TLS-SBD-2]
Assessment of [REQ-TLS-SBD-2]
**Assessment Reference:** The product shall be configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.
**Assessment Objective:** The product is configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Locate the technical documentation indicating the product's trusted root store policy.
- Prepare a web server with TLS signed from a trusted root.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Check that the trusted root policy exists
2. Navigate to the website and observe the results
**Assignment of Verdict:**
-**Pass**:
- The trusted root policy exists
- Navigating to the trusted site succeeds
-**Fail**: Any of the above are not fulfilled.
**Supporting Evidence:**
- Logs or screenshots showing the product's response to the navigation
- Root store policy and listing of trusted roots
### [ACC-EXT-SBD-1]
Assessment of [REQ-EXT-SBD-1]
@@ -861,11 +916,41 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- Console log output from the test extension demonstrated state access or denial.
## 6.4 Secure Updates
Proposed ESR code: SU
### [ACC-TLS-SU-1]
Assessment of [REQ-TLS-SU-1]
**Assessment Reference:** The product's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.
**Assessment Objective:** The product's root store is kept up to date in accordance with the documented policy.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Locate the documented policy describing how and when the trusted root store is updated.
- Capture the initial trusted root store contents.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Exercise the documented root store update mechanism (e.g., product update, separate channel).
2. Capture the trusted root store contents after the update.
3. Compare the change against the documented policy.
**Assignment of Verdict:**
-**Pass**:
- The documented update mechanism functions as documented
- The resulting change to the root store is consistent with the documented policy.
-**Fail**: Either of the above are not fulfilled.
**Supporting Evidence:**
- Documented root store update policy.
- List of trusted roots before and after the update.
### [ACC-EXT-SU-1]
Assessment of [REQ-EXT-SU-1]
@@ -1073,6 +1158,117 @@ Proposed ESR code: CON
In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography assessment criteria.
### [ACC-TLS-CON-1]
Assessment of [REQ-TLS-CON-1]
**Assessment Reference:** The product shall support TLS versions and configurations indicated as "recommended" (R) of the ENISA Agreed Cryptographic Methods [1], and it may support TLS versions and configurations indicated as "legacy" (L).
**Assessment Objective:** The product supports all TLS versions and configurations marked as recommended by ENISA Agreed Cryptographic Methods.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Identify the current list of recommended TLS versions and configurations from ENISA Agreed Cryptographic Methods [1].
- Configure web servers, each serving content under a distinct recommended TLS version/configuration.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to each test server and record whether the connection succeeds.
**Assignment of Verdict:**
-**Pass**: Each recommended TLS version/configuration is reachable from the product.
-**Fail**: The pass condition is not fulfilled.
**Supporting Evidence:**
- Logs or screenshots of each navigation result.
- Reference list of ENISA recommended TLS versions/configurations used.
### [ACC-TLS-CON-2]
Assessment of [REQ-TLS-CON-2]
**Assessment Reference:** The product shall check the full validity of certificate chain through to the root, including for expiration and revocation.
**Assessment Objective:** The product validates the full certificate chain through to the root, including expiration and revocation.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Configure a baseline web server with a valid TLS certificate chained to a trusted root.
- Configure additional web servers with: an expired certificate, a revoked certificate, a certificate chained to a root not in the product's trusted root store, and an incomplete chain.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to the baseline server and record the result.
2. Navigate to each defective-chain server and record the result.
**Assignment of Verdict:**
-**Pass**:
- The baseline server is reachable.
- For each defective-chain server, the product's response visibly differs from the baseline (e.g., blocked, warned, error).
-**Fail**: Either of the above is not fulfilled.
**Supporting Evidence:**
- Logs or screenshots of each navigation result.
- Certificate details for each test server.
### [ACC-TLS-CON-3]
Assessment of [REQ-TLS-CON-3]
**Assessment Reference:** The product shall warn or obstruct the user from interacting with content served over insecure connections, including expired certificates and insecure TLS configurations.
**Assessment Objective:** The product warns or obstructs the user from interacting with content served over insecure connections.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Configure web servers, each serving content over an insecure variant: an expired certificate, a certificate chained to an untrusted root, and an insecure TLS configuration such as a deprecated protocol version or weak cipher.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to each test server.
2. Record the product's UI response and whether content interaction is permitted, with or without an explicit user override.
**Assignment of Verdict:**
-**Pass**: For each insecure variant, the product presents a warning UI or obstructs interaction with the content.
-**Fail**: The pass condition is not fulfilled.
**Supporting Evidence:**
- Screenshots or recordings of the warning/obstruction UI for each variant.
### [ACC-TLS-CON-4]
Assessment of [REQ-TLS-CON-4]
**Assessment Reference:** The product shall implement appropriate technologies to promote or require the use of HTTPS rather than HTTP.
**Assessment Objective:** The product implements one or more technologies that promote or require HTTPS over HTTP.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Configure web servers serving the same content over HTTP and over HTTPS.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to the HTTP variant and observe whether the product upgrades to HTTPS, warns, or blocks.
2. Load an HTTPS page that includes HTTP subresources and observe mixed-content handling.
**Assignment of Verdict:**
-**Pass**: The product applies at least one technology that promotes or requires HTTPS, such as HSTS, HTTPS-First mode, automatic HTTP-to-HTTPS upgrade, or mixed-content blocking.
-**Fail**: The pass condition is not fulfilled.
**Supporting Evidence:**
- Logs or screenshots of HTTP vs HTTPS navigation behaviour.
<mark>Editor's note: REQ-TLS-CON-4 says "appropriate technologies" but doesn't say which. Need to figure out if we need a list or leave it intentionally unspecified.</mark>
### [ACC-EXT-CON-1]
Assessment of [REQ-EXT-CON-1]
@@ -1445,6 +1641,32 @@ The following steps are to be carried out in order:
Proposed ESR code: LOG
### [ACC-TLS-LOG-1]
Assessment of [REQ-TLS-LOG-1]
**Assessment Reference:** The product shall present a user interface giving visibility into the security properties of the connection, including the origin.
**Assessment Objective:** The product presents a user interface giving visibility into the security properties of the connection, including the origin.
**Assessment Preparation:**
- Identify multiple relevant websites with various levels of the security of their connections, at different origins.
- Locate the relevant user interface based on the technical documentation of the product.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Navigate to each of the various websites identified.
2. Open the security UI and observe the information displayed.
**Assignment of Verdict:**
-**Pass**: For each website, the UI includes the URL and any other relevant security properties of the connection.
-**Fail**: Any of the above are not fulfilled.
**Supporting Evidence:**
- Screenshots of security UI for each website
### [ACC-EXT-LOG-1]
Assessment of [REQ-EXT-LOG-1]
@@ -1475,11 +1697,41 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- User interface captures.
## 6.14 Data Removal and Transparency
Proposed ESR code: DRT
### [ACC-TLS-DRT-1]
Assessment of [REQ-TLS-DRT-1]
**Assessment Reference:** The product shall make available functionality to reset TLS-related functionality to the initial safe settings, including selection of algorithms and protocol versions, root certificates, and any other relevant properties.
**Assessment Objective:** The product provides functionality that resets TLS-related settings to the initial safe configuration.
**Assessment Preparation:**
- Install the product from scratch, or reset it to its default settings.
- Capture the initial TLS-related state: enabled algorithms and protocol versions, trusted root certificates, and any other TLS-related settings.
- Locate the reset functionality in the product UI or documentation.
**Assessment Activities:**
The following steps are to be carried out in order:
1. Modify TLS-related state from its initial values, such as disabling a protocol version, adding a custom trusted root, or altering a TLS-related setting.
2. Exercise the reset functionality.
3. Capture the post-reset TLS-related state.
4. Compare the post-reset state against the initial snapshot.
**Assignment of Verdict:**
-**Pass**:
- The reset functionality is available and exercisable.
- The post-reset state matches the initial state across all modified TLS-related properties.
-**Fail**: Either of the above is not fulfilled.
**Supporting Evidence:**
- TLS state snapshots before modification, after modification, and after reset.
