TLS Requirements, continued from Littledan's PR, updated to new structure for...

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.

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.

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.

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.

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.

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]

**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]

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]

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]

**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.

### [ACC-EXT-DRT-1]

Assessment of [REQ-EXT-DRT-1]