EN-304-617.md.backup

   - Explicit "Developer Mode" or "Unreviewed" text
3. Test that browser toolbar shows indicator when developer extensions are active
4. Verify that extension icons have visual badges or overlays
5. Test that browser status area shows developer mode indicator
6. Verify that indicators persist across browser restarts
7. Test that indicators cannot be hidden or disabled by extensions
8. Verify that hovering over indicators explains developer mode risks
9. Test that new tab pages or security dashboards show developer extension warnings
10. Verify that indicators are visually distinct and noticeable
11. Test that multiple developer extensions show cumulative warning
12. Confirm that disabling developer mode removes all indicators

**Pass Criteria**: Developer extensions have persistent visual indicators AND indicators appear in multiple locations AND indicators cannot be hidden AND indicators explain risks on interaction

**Fail Criteria**: No visual indicators exist OR indicators can be hidden OR indicators are too subtle OR no risk explanation available

**Evidence**: Screenshots of developer extension indicators in various UI locations, persistence test results, user visibility testing, indicator interaction demonstrations

**References**:

- Security Indicators Research: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Visual Security Warnings: https://dl.acm.org/doi/10.1145/3290605.3300516

### Assessment: EXT-REQ-26 (Developer mode update disablement)

**Reference**: EXT-2-REQ-8 - Developer mode shall disable automatic extension updates

**Given**: A conformant browser with EXT-2 capability with developer mode enabled

**Task**: Verify that developer mode disables automatic extension updates to prevent developer extensions from silently updating to malicious code without user awareness, ensuring that developers have explicit control over extension versions during development and testing, and preventing attack scenarios where initial benign developer extension updates are replaced with malicious payloads through compromised update mechanisms or developer account takeovers.

**Verification**:

1. Install a developer mode extension with update_url in manifest
2. Verify that automatic updates are disabled for the developer extension
3. Test that browser does not check for updates automatically:
   - Monitor network traffic for update check requests
   - Wait for normal update interval to pass
   - Verify no update checks occur
4. Publish a new version of the extension to the update URL
5. Verify that the extension does not auto-update to new version
6. Test that extension management UI indicates updates are disabled
7. Verify that manual update option is available in UI
8. Test that manual updates require explicit user action
9. Verify that update disablement persists across browser restarts
10. Test that store-installed extensions continue to receive automatic updates
11. Verify that re-installing as store extension re-enables automatic updates
12. Check that extension update policy documentation explains developer mode behavior

**Pass Criteria**: Developer extensions do not auto-update AND no automatic update checks occur AND manual update option exists AND store extensions still update automatically

**Fail Criteria**: Developer extensions auto-update OR update checks occur automatically OR no manual update option OR store extensions lose updates

**Evidence**: Network traffic logs showing no update checks, extension version persistence tests, UI screenshots showing disabled auto-update, manual update flow demonstrations

**References**:

- Extension Update Security: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Updates
- Software Update Best Practices: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final

### Assessment: EXT-REQ-27 (Developer mode activity logging)

**Reference**: EXT-2-REQ-9 - Browser shall log all developer mode extension activities

**Given**: A conformant browser with EXT-2 capability with developer mode enabled

**Task**: Verify that the browser comprehensively logs all developer mode extension activities to provide visibility into potentially risky operations performed by unreviewed extensions, enabling security monitoring, incident investigation, and detection of malicious behavior, ensuring that security teams and advanced users can review what developer extensions are doing and identify suspicious patterns that may indicate compromise or abuse.

**Verification**:

1. Enable developer mode and install test developer extension
2. Access browser logging interface (console, diagnostic logs, or audit logs)
3. Trigger various developer extension activities:
   - Extension installation and loading
   - Permission requests and grants
   - API calls to sensitive interfaces
   - Network requests to external servers
   - Storage access and modifications
   - Content script injections
   - Background script execution
4. Verify that all activities are logged with sufficient detail:
   - Timestamp of activity
   - Extension ID and name
   - Activity type and description
   - Resources or permissions accessed
   - Success or failure status
5. Test that logs include security-relevant events specifically
6. Verify that logs are accessible to users and administrators
7. Test that log retention is appropriate for security analysis
8. Verify that logs can be exported or forwarded to monitoring systems
9. Confirm that logging does not expose sensitive user data
10. Test that log volume is manageable and does not degrade performance
11. Verify that logs distinguish between developer and store extensions
12. Check that critical security events trigger additional logging detail

**Pass Criteria**: All developer extension activities are logged AND logs contain sufficient detail for security analysis AND logs are accessible AND logging preserves user privacy

**Fail Criteria**: Activities are not logged OR log detail is insufficient OR logs are inaccessible OR logging exposes sensitive data

**Evidence**: Log excerpts showing various extension activities, log format and field documentation, export functionality demonstrations, privacy analysis of log content

**References**:

- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

### Assessment: EXT-REQ-28 (Enterprise developer mode control)

**Reference**: EXT-2-REQ-10 - Enterprise policies shall be able to disable developer mode

**Given**: A conformant browser with EXT-2 capability in an enterprise environment

**Task**: Verify that enterprise administrators can completely disable developer mode through policy controls, preventing users from installing unreviewed extensions that could bypass corporate security controls, exfiltrate sensitive data, or compromise compliance requirements, ensuring that organizations can enforce extension security policies appropriate to their risk tolerance and regulatory obligations while still allowing use of approved store extensions.

**Verification**:

1. Access enterprise policy management interface or configuration system
2. Identify policy settings related to developer mode (e.g., DeveloperModeDisabled, ExtensionInstallSources)
3. Configure policy to disable developer mode
4. Deploy policy through enterprise management tools
5. Verify that developer mode toggle is hidden or disabled in browser UI
6. Attempt to enable developer mode through all available methods:
   - Browser settings UI
   - Command-line flags
   - Configuration file modifications
   - Registry entries (Windows) or preference files
7. Verify that all attempts to enable developer mode are blocked
8. Test that error messages clearly indicate policy restriction
9. Verify that users cannot install developer extensions while policy is active
10. Test that previously installed developer extensions are disabled or removed
11. Verify that policy enforcement persists across browser restarts
12. Test that policy cannot be overridden by local user settings
13. Confirm that audit logs show policy enforcement events

**Pass Criteria**: Enterprise policy can disable developer mode AND all bypass attempts fail AND policy enforcement is persistent AND users receive clear error messages

**Fail Criteria**: Developer mode can be enabled despite policy OR policy can be bypassed OR enforcement is inconsistent OR error messages are unclear

**Evidence**: Policy configuration screenshots, developer mode block demonstrations, policy status verification, audit log entries showing enforcement

**References**:

- Enterprise Browser Management: https://chromeenterprise.google/policies/
- Group Policy Configuration: https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge

### Assessment: EXT-REQ-29 (Sideloaded extension warnings)

**Reference**: EXT-3-REQ-9 - Sideloaded extensions shall display prominent security warnings

**Given**: A conformant browser with EXT-3 capability (unrestricted extension installation)

**Task**: Verify that sideloaded extensions (installed outside official stores) display prominent, persistent security warnings to inform users of increased risk, ensuring users understand that sideloaded extensions have not undergone official security review, may contain malicious code, and could compromise their privacy or security, enabling informed decisions about whether to continue using extensions from untrusted sources.

**Verification**:

1. Install a test extension via sideloading (direct file installation, not from store)
2. Verify that installation displays prominent security warning:
   - Warning about unreviewed extension source
   - Explanation of potential security risks
   - Recommendation to only install trusted extensions
   - Option to cancel installation
3. Test that warning requires affirmative user acknowledgment
4. Verify that installed sideloaded extension shows persistent indicators:
   - Visual badge or label in extension list
   - Warning icon on extension toolbar button
   - Status message in extension details
5. Test that browser status area indicates sideloaded extensions are present
6. Verify that new tab page or security dashboard shows sideloaded extension warnings
7. Test that warnings cannot be permanently dismissed or hidden
8. Verify that each browser session shows security status
9. Test that extension permissions page emphasizes sideloaded status
10. Verify that warning messages are clear and explain risks in user-friendly language
11. Test that multiple sideloaded extensions show cumulative risk indicators
12. Confirm that uninstalling sideloaded extension removes all warnings

**Pass Criteria**: Sideloaded extensions show prominent warnings at install AND persistent indicators remain visible AND warnings explain security risks clearly AND warnings cannot be hidden

**Fail Criteria**: No warnings shown OR warnings are dismissible OR risk explanation is unclear OR indicators are too subtle

**Evidence**: Installation warning screenshots, persistent indicator demonstrations, security dashboard views, warning message content analysis

**References**:

- Security Warning Effectiveness: https://www.usenix.org/conference/soups2013/proceedings/presentation/akhawe
- Extension Security Best Practices: https://extensionworkshop.com/documentation/develop/build-a-secure-extension/

### Assessment: EXT-REQ-30 (User extension permission controls)

**Reference**: EXT-3-REQ-10 - Browser shall provide user controls to review and revoke extension permissions

**Given**: A conformant browser with EXT-3 capability with installed extensions

**Task**: Verify that users have granular controls to review all granted extension permissions and revoke specific permissions without uninstalling extensions, enabling users to adjust extension access rights as their security preferences evolve, reducing over-privileged extensions, and providing a mechanism to contain potentially compromised extensions by limiting their access to sensitive APIs or data while investigating security concerns.

**Verification**:

1. Install test extensions with various permission sets
2. Access extension management interface
3. Verify that each extension displays complete list of granted permissions
4. Test that permission list is organized and easy to understand:
   - Grouped by category (site access, API permissions, etc.)
   - Clear descriptions of what each permission enables
   - Visual indicators for high-risk permissions
5. Verify that users can revoke individual permissions through UI controls
6. Test permission revocation for various permission types:
   - Host permissions (site access)
   - API permissions (cookies, webRequest, etc.)
   - Optional permissions previously granted
7. Verify that revoking permissions takes effect immediately
8. Test that extensions handle permission revocation gracefully (no crashes)
9. Verify that revoked permissions persist across browser restarts
10. Test that extensions can request re-grant of revoked permissions with user consent
11. Verify that permission changes are logged for user review
12. Test that revoking critical permissions triggers warning about potential extension breakage
13. Confirm that users can restore default permissions if needed

**Pass Criteria**: All extension permissions are reviewable AND permissions can be individually revoked AND revocation is immediate and persistent AND extensions handle revocation gracefully

**Fail Criteria**: Permissions are not reviewable OR cannot be revoked individually OR revocation causes crashes OR changes do not persist

**Evidence**: Extension permission UI screenshots, permission revocation demonstrations, persistence tests, extension error handling logs, user control workflow recordings

**References**:

- Runtime Permissions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/permissions
- User Control Principles: https://www.w3.org/TR/design-principles/#user-control

### Assessment: EXT-REQ-31 (Sideloaded extension malware scanning)

**Reference**: EXT-3-REQ-11 - Browser shall scan sideloaded extensions for known malware signatures

**Given**: A conformant browser with EXT-3 capability allowing sideloaded extensions

**Task**: Verify that the browser automatically scans sideloaded extensions for known malware signatures before installation, providing baseline protection against well-known malicious extensions even in unrestricted installation environments, detecting common malware families, cryptominers, data stealers, and other threats that have been previously identified and catalogued, reducing the risk of users inadvertently installing extensions with confirmed malicious behavior.

**Verification**:

1. Obtain or create test extension packages with known malware signatures:
   - EICAR test file embedded in extension
   - Known malicious extension samples (from malware repositories)
   - Extensions with known cryptominer code
   - Extensions with data exfiltration patterns
2. Attempt to install each malicious test extension via sideloading
3. Verify that browser performs pre-installation malware scan
4. Verify that malicious extensions are blocked before installation with clear warnings:
   - Specific threat description (malware type detected)
   - Recommendation to not proceed
   - Option to report malicious extension
5. Test that scan covers all extension components:
   - JavaScript files
   - Background scripts and content scripts
   - Embedded libraries
   - WebAssembly modules
6. Verify that clean extensions pass scan and install normally
7. Test that scan results are logged for security review
8. Verify that malware definitions are updated regularly
9. Test that scan performance does not significantly delay installation
10. Verify that users are informed about scan process
11. Test that detected malware can be quarantined or deleted
12. Confirm that scan cannot be disabled or bypassed by users

**Pass Criteria**: Malware scanning occurs before installation AND known malware is detected and blocked AND scan covers all extension components AND malware definitions are updated regularly

**Fail Criteria**: No malware scanning occurs OR known malware is not detected OR scan can be bypassed OR definitions are outdated

**Evidence**: Malware detection screenshots, scan log files, test results with various malware samples, malware definition update verification, performance impact analysis

**References**:

- Malware Detection in Browser Extensions: https://research.google/pubs/pub43824/
- Extension Security Analysis: https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/carlini

### Assessment: EXT-REQ-32 (Extension security event logging)

**Reference**: EXT-3-REQ-12 - All extension security events shall be logged for review

**Given**: A conformant browser with EXT-3 capability with extensions installed

**Task**: Verify that all extension security events are comprehensively logged to provide complete audit trail for security monitoring, incident response, and forensic analysis, enabling detection of malicious extension behavior, permission abuse, or security policy violations, ensuring that administrators and security teams have visibility into extension activities that could indicate compromise or misuse in environments with unrestricted extension installation.

**Verification**:

1. Install various test extensions (store, sideloaded, developer mode)
2. Access browser security logging interface
3. Trigger various extension security events:
   - Extension installation from different sources
   - Permission requests and grants/denials
   - Sensitive API usage (debugger, management, privacy)
   - Cross-extension communication attempts
   - Native messaging connections
   - WebRequest interception and modification
   - Suspicious network requests to unusual domains
   - Extension update installations
   - Extension crashes or security errors
   - User permission revocations
4. Verify that all events are logged with comprehensive details:
   - Timestamp with timezone
   - Extension ID, name, and version
   - Event type and severity level
   - User actions or automated triggers
   - Success/failure status
   - Affected resources (URLs, permissions, APIs)
   - Source of extension (store, sideloaded, developer)
5. Test that logs are structured for automated analysis (JSON, CSV, syslog format)
6. Verify that logs can be filtered by severity, extension, or event type
7. Test that logs are retained for appropriate security analysis period
8. Verify that logs can be exported or forwarded to SIEM systems
9. Confirm that logging does not expose user passwords or sensitive personal data
10. Test that high-severity events trigger immediate alerts or notifications
11. Verify that logs include contextual information for investigation
12. Test that log tampering is prevented or detected

**Pass Criteria**: All extension security events are logged AND logs contain comprehensive detail AND logs are structured and filterable AND logs can be exported to SIEM AND logging preserves privacy

**Fail Criteria**: Security events are not logged OR logs lack necessary detail OR logs cannot be analyzed OR logs expose sensitive data OR logs can be tampered with

**Evidence**: Log samples showing various event types, log schema documentation, SIEM integration demonstrations, privacy analysis, retention policy verification, alert configuration examples

**References**:

- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Security Information and Event Management: https://csrc.nist.gov/glossary/term/security_information_and_event_management

## 6.3 Cryptographic Security Assessments

This section covers assessment procedures for requirements ENC-REQ-1 through ENC-REQ-21, addressing TLS/SSL configuration, certificate validation, cryptographic API usage, secure random number generation, and encryption key management.

### Assessment: ENC-REQ-1 (TLS 1.3+ support)

**Reference**: ENC-REQ-1 - Browser shall support TLS 1.3 or higher for all network communications

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that the browser supports modern TLS 1.3 protocol to protect network communications from downgrade attacks, reduce latency through improved handshake efficiency, and provide forward secrecy through ephemeral key exchange, ensuring that user traffic benefits from the latest cryptographic protections against eavesdropping and man-in-the-middle attacks.

**Verification**:

1. Configure a test web server to support multiple TLS versions: TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3
2. Navigate the browser to each server endpoint and capture the TLS handshake using packet capture tools (Wireshark, tcpdump)
3. Verify that the browser successfully negotiates TLS 1.3 when available
4. Configure the server to offer only TLS 1.3 and verify successful connection
5. Test TLS 1.3 features: 0-RTT resumption, encrypted SNI (ESNI/ECH), and post-handshake authentication
6. Use browser DevTools Security tab to verify TLS version for the connection
7. Test that browser prefers TLS 1.3 over older versions when both are available
8. Verify that TLS 1.3 cipher suites are properly supported (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256)
9. Confirm that browser successfully negotiates TLS 1.3 when server supports it
10. Verify that TLS 1.3 is preferred over TLS 1.2 when both are available
11. Check that browser Security panel shows "TLS 1.3" as the protocol version
12. Validate that packet captures confirm TLS 1.3 handshake structure (single round-trip)
13. Confirm that TLS 1.3-specific features (0-RTT, encrypted extensions) function correctly
14. Verify that browser supports all mandatory TLS 1.3 cipher suites

**Pass Criteria**: Browser successfully negotiates TLS 1.3 connections AND prefers TLS 1.3 over older versions when available

**Fail Criteria**: Browser cannot establish TLS 1.3 connections OR prefers older TLS versions when TLS 1.3 is available

**Evidence**: Wireshark packet captures showing TLS 1.3 handshake, DevTools Security tab screenshots, server logs showing negotiated protocol version, cipher suite listings

**References**:

- RFC 8446 - TLS 1.3 Specification: https://datatracker.ietf.org/doc/html/rfc8446
- Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/
- NIST SP 800-52 Rev. 2 - TLS Guidelines: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
- Qualys SSL Labs - SSL/TLS Best Practices: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
- Chrome Network Security: https://www.chromium.org/Home/chromium-security/education/tls/

### Assessment: ENC-REQ-2 (Certificate validation)

**Reference**: ENC-REQ-2 - Browser shall perform complete certificate chain validation including expiry, revocation, and trust anchor verification

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that the browser performs comprehensive certificate chain validation to prevent man-in-the-middle attacks using expired, self-signed, or fraudulent certificates, ensuring that only connections to servers with valid certificates from trusted certificate authorities are established without warnings, protecting users from impersonation attacks and ensuring transport layer authentication.

**Verification**:

1. Set up test scenarios with various certificate configurations:
   - Valid certificate from trusted CA
   - Expired certificate
   - Self-signed certificate
   - Certificate with wrong hostname (CN/SAN mismatch)
   - Certificate with incomplete chain
   - Certificate from untrusted CA
   - Revoked certificate
2. Navigate to each test endpoint and observe browser behavior
3. Verify that browser displays appropriate security warnings for invalid certificates
4. Test that users cannot bypass critical certificate errors without explicit acknowledgment
5. Verify certificate chain validation using browser DevTools Security tab
6. Test extended validation (EV) certificate display
7. Capture and analyze the certificate validation process
8. Test certificate validation with intermediate CA certificates
9. Confirm that valid certificates from trusted CAs are accepted without warnings
10. Verify that expired certificates trigger security warnings and connection blocks
11. Check that self-signed certificates are rejected with clear error messages
12. Validate that hostname mismatches are detected and reported
13. Confirm that incomplete certificate chains are rejected
14. Verify that certificates from untrusted CAs trigger warnings
15. Check that users should explicitly acknowledge risk to bypass warnings
16. Validate that EV certificates display organization name in browser UI

**Pass Criteria**: All invalid certificates are detected and reported with appropriate warnings AND users cannot silently bypass critical errors

**Fail Criteria**: Any invalid certificate is accepted without warning OR users can bypass critical errors without explicit acknowledgment

**Evidence**: Screenshots of certificate warning dialogs, DevTools Security tab showing certificate validation status, error console logs, packet captures showing certificate exchange

**References**:

- RFC 5280 - X.509 Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280
- CA/Browser Forum Baseline Requirements: https://cabforum.org/baseline-requirements-documents/
- OWASP Transport Layer Protection Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
- Mozilla Root Store Policy: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
- Chrome Certificate Transparency Policy: https://github.com/chromium/ct-policy

### Assessment: ENC-REQ-3 (Certificate pinning support)

**Reference**: ENC-REQ-3 - Browser shall support HTTP Public Key Pinning (HPKP) or alternative certificate pinning mechanisms

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that the browser enforces certificate pinning to prevent man-in-the-middle attacks against critical domains by rejecting connections to pinned sites that present certificates from unexpected certificate authorities, even if those CAs are otherwise trusted, ensuring that even with a compromised certificate authority, attackers cannot impersonate pinned origins through fraudulent certificate issuance.

**Verification**:

1. Configure a test server to send Public-Key-Pins or Expect-CT headers
2. Navigate to the test server and verify that pins are stored by the browser
3. Attempt to connect with a certificate that violates the pin (different public key)
4. Verify that the browser rejects the connection due to pin validation failure
5. Test pin expiration and max-age directive behavior
6. Test includeSubDomains directive for pin inheritance
7. Test report-uri directive for pin violation reporting
8. Examine browser's HPKP/pin storage (chrome://net-internals/#hsts for Chromium)
9. Test static pins for built-in domains (e.g., Google properties)
10. Confirm that browser correctly stores certificate pins from HTTP headers
11. Verify that connections with mismatched certificates are rejected
12. Check that pin validation errors display clear security warnings
13. Validate that pins expire according to max-age directive
14. Confirm that includeSubDomains directive applies pins to subdomains
15. Verify that pin violations are reported to specified report-uri
16. Check that browser maintains persistent pin storage across sessions
17. Validate that static pins for built-in domains are enforced

**Pass Criteria**: Browser enforces certificate pins correctly AND rejects connections that violate pin requirements

**Fail Criteria**: Browser ignores certificate pins OR allows connections that violate pin requirements

**Evidence**: Screenshots of pin validation errors, browser internal state showing stored pins, network logs showing rejected connections, pin violation reports

**References**:

- RFC 7469 - HTTP Public Key Pinning (HPKP): https://datatracker.ietf.org/doc/html/rfc7469
- Expect-CT Header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT
- OWASP Certificate Pinning: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- Chrome HPKP Guidance: https://www.chromium.org/hsts/

### Assessment: ENC-REQ-4 (HSTS enforcement)

**Reference**: ENC-REQ-4 - Browser shall enforce HTTP Strict Transport Security (HSTS) to prevent protocol downgrade attacks

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that HSTS enforcement prevents protocol downgrade attacks where attackers strip TLS to intercept credentials, ensuring all connections to HSTS-enabled domains use HTTPS even if users or applications attempt insecure HTTP connections. This protection is critical for preventing man-in-the-middle attacks that exploit the initial HTTP connection window before users type "https://" or before redirects to HTTPS occur.

**Verification**:

1. Configure a test server to send Strict-Transport-Security header: `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`
2. Navigate to https://test.example.com and verify HSTS header is received
3. Attempt to navigate to http://test.example.com (non-HTTPS) and verify automatic upgrade to HTTPS
4. Test that browser stores HSTS policy persistently across sessions
5. Verify includeSubDomains directive applies HSTS to all subdomains
6. Test HSTS policy expiration by setting short max-age values
7. Examine browser's HSTS storage (chrome://net-internals/#hsts)
8. Test HSTS preload list for well-known domains
9. Attempt to bypass HSTS with user override and verify it's prevented
10. Browser receives and processes Strict-Transport-Security header
11. HTTP requests are automatically upgraded to HTTPS for HSTS domains
12. HSTS policy persists across browser sessions
13. includeSubDomains directive correctly applies to subdomains
14. HSTS policies expire according to max-age directive
15. Preloaded domains enforce HTTPS even on first visit
16. Users cannot bypass HSTS enforcement
17. Browser maintains HSTS state in persistent storage

**Pass Criteria**: All HTTP requests to HSTS domains are automatically upgraded to HTTPS AND HSTS policies are enforced persistently

**Fail Criteria**: HTTP requests are not upgraded OR HSTS policies can be bypassed OR policies do not persist

**Evidence**: Network logs showing HTTP to HTTPS upgrades, browser HSTS storage screenshots, packet captures showing only HTTPS connections, console logs

**References**:

- RFC 6797 - HTTP Strict Transport Security (HSTS): https://datatracker.ietf.org/doc/html/rfc6797
- HSTS Preload List: https://hstspreload.org/
- OWASP HSTS Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
- MDN HSTS Documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
- Chromium HSTS Implementation: https://www.chromium.org/hsts/

### Assessment: ENC-REQ-5 (Mixed content blocking)

**Reference**: ENC-REQ-5 - Browser shall block mixed content (HTTP resources on HTTPS pages) to prevent downgrade attacks

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that mixed content blocking prevents protocol downgrade attacks where attackers inject HTTP resources into HTTPS pages to intercept data or execute malicious scripts. Blocking mixed content maintains the security guarantees of HTTPS by preventing unencrypted channels that could be exploited by network-level attackers to compromise the page's integrity and confidentiality.

**Verification**:

1. Create an HTTPS test page (https://test.example.com) that loads various HTTP resources:
   - HTTP scripts: `<script src="http://example.com/script.js">`
   - HTTP stylesheets: `<link href="http://example.com/style.css">`
   - HTTP iframes: `<iframe src="http://example.com/page.html">`
   - HTTP images: `<img src="http://example.com/image.jpg">`
   - HTTP XHR/fetch requests
   - HTTP form submission actions
2. Navigate to the test page and observe browser behavior
3. Verify that active mixed content (scripts, stylesheets, iframes) is blocked
4. Test browser's handling of passive mixed content (images, audio, video)
5. Check browser console for mixed content warnings
6. Test Content-Security-Policy: block-all-mixed-content directive
7. Verify that upgrade-insecure-requests CSP directive upgrades HTTP to HTTPS
8. Test mixed content indicator in browser address bar
9. Active mixed content (scripts, stylesheets, iframes) is completely blocked
10. Browser console displays clear mixed content blocking messages
11. Passive mixed content may load with warnings (or be blocked in strict mode)
12. Mixed content indicator appears in browser address bar/security indicator
13. CSP block-all-mixed-content directive blocks all mixed content
14. CSP upgrade-insecure-requests upgrades HTTP resources to HTTPS
15. Form submissions to HTTP URLs are blocked or warned
16. Users are warned about security implications of mixed content

**Pass Criteria**: All active mixed content is blocked AND clear warnings are displayed in console and UI

**Fail Criteria**: Active mixed content loads successfully OR no warnings are displayed

**Evidence**: Browser console screenshots showing blocked resources, network panel showing blocked requests, security indicator screenshots, DevTools showing CSP violations

**References**:

- W3C Mixed Content Specification: https://w3c.github.io/webappsec-mixed-content/
- MDN Mixed Content Documentation: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
- Chrome Mixed Content Policy: https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
- Upgrade Insecure Requests: https://www.w3.org/TR/upgrade-insecure-requests/

### Assessment: ENC-REQ-6 (Certificate Transparency)

**Reference**: ENC-REQ-6 - Browser shall enforce Certificate Transparency (CT) requirements for all publicly trusted certificates

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that Certificate Transparency enforcement detects rogue certificates issued by compromised or malicious certificate authorities, preventing attackers from using fraudulently issued certificates for man-in-the-middle attacks. CT ensures all publicly trusted certificates are logged in append-only public ledgers, making unauthorized certificate issuance detectable and accountable.

**Verification**:

1. Set up test servers with certificates that have different CT compliance levels:
   - Certificate with embedded SCTs (Signed Certificate Timestamps)
   - Certificate with SCTs delivered via TLS extension
   - Certificate with SCTs delivered via OCSP stapling
   - Certificate without any SCTs
2. Navigate to each test server and observe browser behavior
3. Verify that browser requires CT for publicly trusted certificates
4. Check DevTools Security tab for CT information
5. Test that certificates without valid SCTs are rejected
6. Verify that browser validates SCT signatures
7. Test CT enforcement for different certificate types (DV, OV, EV)
8. Examine browser's CT policy compliance
9. Browser accepts certificates with valid SCTs
10. Certificates without SCTs are rejected with security errors
11. DevTools Security tab displays CT compliance status
12. Browser validates SCT signatures from known logs
13. CT is enforced for all publicly trusted certificates
14. Multiple SCT delivery mechanisms are supported
15. Browser maintains list of trusted CT log servers
16. CT violations trigger certificate errors

**Pass Criteria**: Browser enforces CT requirements AND rejects certificates without valid SCTs

**Fail Criteria**: Browser accepts certificates without SCTs OR does not validate SCT signatures

**Evidence**: DevTools Security tab screenshots showing CT status, certificate error dialogs for non-CT certificates, network logs showing SCT validation, browser CT policy configuration

**References**:

- RFC 6962 - Certificate Transparency: https://datatracker.ietf.org/doc/html/rfc6962
- Chrome CT Policy: https://github.com/chromium/ct-policy/blob/master/ct_policy.md
- Certificate Transparency Overview: https://certificate.transparency.dev/
- Google CT Log List: https://www.gstatic.com/ct/log_list/v3/all_logs_list.json
- CT Monitoring: https://developers.google.com/web/updates/2017/10/certificate-transparency

### Assessment: ENC-REQ-7 (OCSP stapling)

**Reference**: ENC-REQ-7 - Browser shall support OCSP stapling for efficient certificate revocation checking

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that OCSP stapling support enables efficient certificate revocation checking without privacy leaks, preventing attackers from using revoked certificates while avoiding OCSP responder queries that reveal user browsing patterns. Stapling moves the revocation check to the server, improving performance and privacy while maintaining security against compromised certificates.

**Verification**:

1. Configure a test server to support OCSP stapling (include OCSP response in TLS handshake)
2. Navigate to the test server and capture the TLS handshake using packet capture tools
3. Verify that browser receives and validates the stapled OCSP response
4. Test server without OCSP stapling and verify browser falls back to OCSP responder query
5. Configure OCSP response indicating certificate is revoked and verify browser rejection
6. Test OCSP response validation including signature verification
7. Measure performance difference between stapled and non-stapled OCSP
8. Test OCSP Must-Staple certificate extension enforcement
9. Verify handling of expired or invalid OCSP responses
10. Browser successfully receives and validates stapled OCSP responses
11. Packet captures show OCSP response in TLS handshake (CertificateStatus message)
12. Browser validates OCSP response signatures
13. Revoked certificates are rejected based on OCSP response
14. Browser falls back to direct OCSP query when stapling unavailable
15. OCSP Must-Staple extension is enforced (if present)
16. Performance metrics show faster connection with stapling
17. Invalid OCSP responses trigger appropriate error handling

**Pass Criteria**: Browser correctly validates stapled OCSP responses AND rejects revoked certificates

**Fail Criteria**: Browser ignores OCSP responses OR accepts revoked certificates

**Evidence**: Packet captures showing stapled OCSP in TLS handshake, certificate error screenshots for revoked certificates, performance measurements, DevTools Security tab showing OCSP status

**References**:

- RFC 6066 - TLS Extension: OCSP Status Request: https://datatracker.ietf.org/doc/html/rfc6066#section-8
- RFC 6960 - Online Certificate Status Protocol (OCSP): https://datatracker.ietf.org/doc/html/rfc6960
- OCSP Stapling Explained: https://www.digicert.com/kb/ssl-support/what-is-ocsp-stapling.htm
- OCSP Must-Staple: https://scotthelme.co.uk/ocsp-must-staple/

### Assessment: ENC-REQ-8 (Cipher suite restrictions)

**Reference**: ENC-REQ-8 - Browser shall support only secure cipher suites and disable weak or deprecated algorithms

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that cipher suite restrictions prevent cryptographic weaknesses from being exploited by attackers to break TLS encryption, ensuring only modern algorithms resistant to known attacks are used. Rejecting weak ciphers like RC4, DES, and export-grade algorithms prevents downgrade attacks and ensures forward security against future cryptanalysis.

**Verification**:

1. Configure test servers with various cipher suites:
   - Strong: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
   - Acceptable: TLS_AES_128_GCM_SHA256, ECDHE-RSA-AES128-GCM-SHA256
   - Weak: RC4, DES, 3DES, NULL ciphers
   - Export-grade ciphers
2. Test browser connection to each server configuration
3. Verify that browser refuses weak cipher suites
4. Capture cipher suite negotiation using packet analysis
5. Test browser's cipher suite preference order
6. Verify that AEAD (Authenticated Encryption with Associated Data) ciphers are preferred
7. Test that CBC-mode ciphers are avoided or deprioritized
8. Examine browser's supported cipher suite list
9. Test cipher suite restrictions for different TLS versions
10. Browser successfully negotiates strong cipher suites
11. Weak cipher suites (RC4, DES, 3DES, NULL) are rejected
12. Connection fails when only weak ciphers are available
13. Browser prefers AEAD ciphers over CBC-mode ciphers
14. Cipher suite negotiation follows secure ordering
15. Export-grade ciphers are completely disabled
16. DevTools shows negotiated cipher suite
17. Browser supports all modern recommended cipher suites

**Pass Criteria**: Browser only accepts strong cipher suites AND rejects all weak or deprecated ciphers

**Fail Criteria**: Browser accepts any weak cipher suite OR fails to negotiate strong ciphers when available

**Evidence**: Packet captures showing cipher suite negotiation, DevTools Security tab showing negotiated cipher, server logs, connection error screenshots for weak cipher servers

**References**:

- Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/
- NIST SP 800-52 Rev. 2 - TLS Guidelines: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
- RFC 8446 - TLS 1.3 Cipher Suites: https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4
- IANA TLS Cipher Suite Registry: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
- Qualys SSL Labs - Cipher Suite Guidance: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

### Assessment: ENC-REQ-9 (Perfect forward secrecy)

**Reference**: ENC-REQ-9 - Browser shall support and prefer cipher suites with perfect forward secrecy (PFS)

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that perfect forward secrecy prevents retrospective decryption attacks where adversaries record encrypted traffic and later compromise server private keys to decrypt historical sessions. PFS ensures that even if long-term keys are compromised, past TLS sessions remain secure because session keys were ephemeral and never stored.

**Verification**:

1. Configure test servers with different key exchange mechanisms:
   - ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) - provides PFS
   - DHE (Diffie-Hellman Ephemeral) - provides PFS
   - RSA key exchange - no PFS
2. Test browser connection to each server configuration
3. Verify that browser prefers ECDHE/DHE over static RSA key exchange
4. Capture TLS handshake to confirm ephemeral key exchange
5. Test that browser supports multiple elliptic curves (X25519, P-256, P-384)
6. Verify proper DH parameter size enforcement (minimum 2048 bits)
7. Test TLS 1.3 behavior (all cipher suites provide PFS)
8. Examine cipher suite preference order for PFS priority
9. Test connection failure when only non-PFS ciphers are available
10. Browser successfully negotiates ECDHE/DHE cipher suites
11. Browser prefers PFS cipher suites over non-PFS alternatives
12. Packet captures show ephemeral key exchange in handshake
13. Browser supports modern elliptic curves (X25519 preferred)
14. DHE parameters meet minimum security requirements (2048+ bits)
15. TLS 1.3 connections always provide PFS
16. DevTools Security tab indicates PFS status
17. Browser may reject or deprioritize non-PFS cipher suites

**Pass Criteria**: Browser prefers PFS cipher suites when available AND successfully negotiates ephemeral key exchange

**Fail Criteria**: Browser prefers non-PFS ciphers over PFS alternatives OR fails to negotiate PFS key exchange

**Evidence**: Packet captures showing ECDHE/DHE key exchange, DevTools Security tab showing PFS cipher suite, connection test results, cipher suite preference analysis

**References**:

- RFC 8446 - TLS 1.3 (all cipher suites provide PFS): https://datatracker.ietf.org/doc/html/rfc8446
- Perfect Forward Secrecy Explained: https://scotthelme.co.uk/perfect-forward-secrecy/
- OWASP TLS Cheat Sheet - Forward Secrecy: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#forward-secrecy
- Mozilla Server Side TLS Guidelines: https://wiki.mozilla.org/Security/Server_Side_TLS

### Assessment: ENC-REQ-10 (Revocation checking)

**Reference**: ENC-REQ-10 - Browser shall perform certificate revocation checking via OCSP and/or CRL mechanisms

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that certificate revocation checking prevents attackers from using compromised or fraudulently obtained certificates that have been revoked by the issuing CA. Checking revocation status ensures browsers reject certificates known to be untrustworthy, protecting users from man-in-the-middle attacks using stolen or misused certificates even after they've been marked as invalid.

**Verification**:

1. Set up test certificates with different revocation configurations:
   - Valid certificate with OCSP responder URL
   - Valid certificate with CRL distribution point
   - Revoked certificate (marked as revoked in OCSP/CRL)
   - Certificate without revocation information
2. Navigate to servers using each certificate type
3. Verify that browser checks certificate revocation status
4. Test OCSP responder queries (use network monitoring)
5. Test CRL download and parsing
6. Configure OCSP responder to return "revoked" status and verify browser rejection
7. Test soft-fail vs hard-fail behavior when revocation check is unavailable
8. Measure performance impact of revocation checking
9. Test browser's revocation checking cache behavior
10. Browser performs OCSP queries for certificates with OCSP URLs
11. Browser downloads and processes CRLs when available
12. Revoked certificates are rejected with clear error messages
13. Browser caches revocation check results appropriately
14. OCSP responses are validated (signature, freshness)
15. CRL validity period is checked
16. Browser handles revocation check failures gracefully
17. Network panel shows OCSP/CRL requests

**Pass Criteria**: Browser performs revocation checks AND rejects revoked certificates with clear error messages

**Fail Criteria**: Browser skips revocation checking OR accepts revoked certificates

**Evidence**: Network logs showing OCSP/CRL requests, certificate error screenshots for revoked certificates, packet captures, DevTools showing revocation status, performance measurements

**References**:

- RFC 6960 - Online Certificate Status Protocol (OCSP): https://datatracker.ietf.org/doc/html/rfc6960
- RFC 5280 - Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280
- Chrome CRLSet Mechanism: https://www.imperialviolet.org/2012/02/05/crlsets.html
- OWASP Certificate Revocation: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning

### Assessment: ENC-REQ-11 (Web Crypto API compliance)

**Reference**: ENC-REQ-11 - Browser shall implement W3C Web Cryptography API for JavaScript cryptographic operations

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that Web Crypto API compliance provides secure, browser-native cryptographic operations preventing developers from implementing insecure custom cryptography that could be vulnerable to timing attacks, weak random number generation, or algorithmic flaws. Restricting the API to secure contexts ensures cryptographic keys and operations are only available over HTTPS, preventing network attackers from intercepting keys.

**Verification**:

1. Create test web page accessing window.crypto.subtle API
2. Test key generation for various algorithms:
   - RSA-OAEP, RSA-PSS (2048, 3072, 4096 bits)
   - ECDSA, ECDH (P-256, P-384, P-521 curves)
   - AES-GCM, AES-CBC (128, 256 bits)
   - HMAC with various hash functions
3. Test encryption/decryption operations with generated keys
4. Test signing and verification operations
5. Test key derivation functions (PBKDF2, HKDF)
6. Test key import/export in various formats (JWK, PKCS8, SPKI, raw)
7. Verify that subtle crypto operations are only available in secure contexts (HTTPS)
8. Test that cryptographic keys can be marked as non-extractable
9. Test key usage constraints (encrypt, decrypt, sign, verify, etc.)
10. Verify proper error handling for invalid parameters
11. window.crypto.subtle is available in secure contexts only
12. All mandatory algorithms are supported
13. Key generation produces keys of requested type and size
14. Encrypt/decrypt operations work correctly with proper padding
15. Sign/verify operations validate signatures correctly
16. Key derivation functions produce deterministic results
17. Non-extractable keys cannot be exported
18. Key usage constraints are enforced
19. Operations fail appropriately in insecure contexts (HTTP)
20. Error messages are clear and informative

**Pass Criteria**: All Web Crypto API operations function correctly AND API is restricted to secure contexts

**Fail Criteria**: Required algorithms are missing OR API is available in insecure contexts OR operations produce incorrect results

**Evidence**: Console logs showing successful crypto operations, test result screenshots, code demonstrating API usage, error messages for insecure context access

**References**:

- W3C Web Cryptography API Specification: https://www.w3.org/TR/WebCryptoAPI/
- MDN Web Crypto API Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API
- Web Crypto API Examples: https://github.com/diafygi/webcrypto-examples
- OWASP Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
- Chrome Web Crypto Implementation: https://www.chromium.org/blink/webcrypto/

### Assessment: ENC-REQ-12 (Secure random number generation)

**Reference**: ENC-REQ-12 - Browser shall provide cryptographically secure random number generation via Crypto.getRandomValues()

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that cryptographically secure random number generation prevents predictability attacks where weak randomness allows attackers to guess session tokens, cryptographic keys, or authentication nonces. High-quality entropy ensures generated values are unpredictable and cannot be reproduced, which is essential for secure key generation, token creation, and cryptographic operations.

**Verification**:

1. Create test page calling window.crypto.getRandomValues() with various typed arrays:
   - Uint8Array, Uint16Array, Uint32Array
   - Different array sizes (1 byte to 65536 bytes)
2. Generate large samples of random data (millions of bytes)
3. Test statistical properties of generated random data:
   - Frequency test (chi-square)
   - Runs test
   - Entropy analysis
4. Verify that repeated calls produce different values
5. Test that maximum size limit (65536 bytes) is enforced
6. Verify proper error handling for invalid parameters
7. Test that random values are available in both secure and insecure contexts
8. Compare randomness quality across multiple browser sessions
9. Test performance of random number generation
10. window.crypto.getRandomValues() is available and functional
11. Generated values pass statistical randomness tests
12. Repeated calls produce different, unpredictable values
13. All typed array types are supported
14. Maximum size limit (65536 bytes) is enforced
15. QuotaExceededError thrown for oversized requests
16. Random values have sufficient entropy (>= 7.9 bits per byte)
17. Performance is acceptable (can generate MBs per second)
18. API is available in all contexts (secure and insecure)

**Pass Criteria**: Generated random values pass statistical tests AND have sufficient entropy for cryptographic use

**Fail Criteria**: Random values show statistical bias OR have insufficient entropy OR values are predictable

**Evidence**: Statistical test results, entropy analysis graphs, performance benchmarks, console logs showing API usage, test code with results

**References**:

- W3C Web Cryptography API - getRandomValues: https://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues
- MDN Crypto.getRandomValues(): https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues
- NIST SP 800-22 - Statistical Tests for Random Number Generators: https://csrc.nist.gov/publications/detail/sp/800-22/rev-1a/final
- Random.org - Statistical Tests: https://www.random.org/analysis/
- OWASP Cryptographic Storage - Random Number Generation: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation

### Assessment: ENC-REQ-13 (SubResource Integrity)

**Reference**: ENC-REQ-13 - Browser shall enforce Subresource Integrity (SRI) for externally loaded scripts and stylesheets

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that Subresource Integrity enforcement prevents supply chain attacks where compromised CDNs or third-party servers deliver malicious modified scripts or stylesheets. SRI ensures that external resources match their expected cryptographic hashes, detecting unauthorized modifications that could inject malware, steal credentials, or compromise user data even if the hosting server is compromised.

**Verification**:

1. Create test page loading external resources with integrity attributes:
   ```html
   <script src="https://cdn.example.com/lib.js"
           integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
           crossorigin="anonymous"></script>
   <link href="https://cdn.example.com/style.css"
         integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"
         crossorigin="anonymous">
   ```
2. Verify that resources with correct integrity hashes load successfully
3. Modify resource content to mismatch integrity hash and verify blocking
4. Test multiple hash algorithms: sha256, sha384, sha512
5. Test multiple integrity values (fallback hashes)
6. Test CORS requirement for cross-origin SRI resources
7. Verify browser console errors for SRI failures
8. Test SRI with different resource types (scripts, stylesheets, preload links)
9. Test that SRI failures prevent script execution/style application
10. Resources with matching integrity hashes load and execute successfully
11. Resources with mismatched hashes are blocked from loading
12. Browser console displays clear SRI violation errors
13. Multiple hash algorithms (sha256, sha384, sha512) are supported
14. Multiple integrity values allow fallback verification
15. Cross-origin resources require proper CORS headers for SRI
16. SRI failures prevent resource execution/application
17. Network panel shows blocked resources with SRI violations
18. Page functionality degrades gracefully when SRI blocks resources

**Pass Criteria**: Resources with correct integrity hashes load successfully AND resources with mismatched hashes are blocked with clear errors

**Fail Criteria**: Resources with mismatched hashes load and execute OR no error messages displayed

**Evidence**: Browser console screenshots showing SRI errors, network panel showing blocked resources, test page demonstrating SRI enforcement, DevTools showing integrity attribute validation

**References**:

- W3C Subresource Integrity Specification: https://www.w3.org/TR/SRI/
- MDN Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- SRI Hash Generator: https://www.srihash.org/
- OWASP SRI Guidance: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#subresource-integrity
- Chrome SRI Implementation: https://www.chromium.org/Home/chromium-security/education/tls/

### Assessment: ENC-REQ-14 (Encrypted SNI)

**Reference**: ENC-REQ-14 - Browser shall support Encrypted Server Name Indication (ESNI/ECH) to prevent SNI-based censorship and surveillance

**Given**: A conformant browser with encryption capability (ENC-3 or higher)

**Task**: Verify that Encrypted SNI support prevents network surveillance and censorship where adversaries monitor TLS handshakes to identify which websites users visit, enabling targeted blocking or surveillance. Encrypting SNI protects user privacy by hiding the destination hostname from network observers, preventing traffic analysis attacks that reveal browsing patterns even when connections use HTTPS.

**Verification**:

1. Configure a test server supporting Encrypted Client Hello (ECH) or ESNI
2. Publish ECH configuration in DNS (TLS HTTPS record type 65)
3. Navigate browser to the test server
4. Capture TLS handshake using packet analysis tools
5. Verify that SNI extension is encrypted in ClientHello message
6. Test fallback behavior when ECH is unavailable
7. Test that cleartext SNI is not visible in packet captures
8. Verify browser DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) usage for ECH config retrieval
9. Test ECH with split-horizon DNS configurations
10. Examine browser settings for ECH/ESNI enablement
11. Browser successfully negotiates ECH/ESNI when available
12. SNI extension is not visible in cleartext in packet captures
13. ClientHello contains encrypted_client_hello extension
14. Browser retrieves ECH configuration via DNS
15. Fallback to cleartext SNI works when ECH unavailable
16. DNS queries for ECH config are encrypted (DoH/DoT)
17. Browser DevTools or internal pages show ECH status
18. Connection succeeds with ECH-enabled servers

**Pass Criteria**: Browser encrypts SNI when ECH is available AND cleartext SNI is not visible in packet captures

**Fail Criteria**: SNI is transmitted in cleartext when ECH is available OR browser doesn't support ECH

**Evidence**: Packet captures showing encrypted ClientHello, Wireshark analysis showing absence of cleartext SNI, DNS query logs showing ECH config retrieval, browser configuration screenshots

**References**:

- RFC 8744 - Encrypted Server Name Indication (ESNI): https://datatracker.ietf.org/doc/html/rfc8744
- Encrypted Client Hello (ECH) Draft: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
- Cloudflare ECH Announcement: https://blog.cloudflare.com/encrypted-client-hello/
- Mozilla ECH Implementation: https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello
- Chrome ECH Status: https://chromestatus.com/feature/6196703843581952

### Assessment: ENC-REQ-15 (Certificate error UI)

**Reference**: ENC-REQ-15 - Browser shall display clear, prominent warnings for certificate errors with appropriate risk communication

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that certificate error UI effectively warns users about man-in-the-middle attacks or compromised servers before they transmit sensitive data to untrusted connections. Clear, prominent warnings with appropriate risk communication prevent users from inadvertently trusting malicious certificates, while making bypass actions deliberately difficult discourages risky behavior that could expose credentials or personal information.

**Verification**:

1. Create test scenarios for various certificate errors:
   - Expired certificate
   - Untrusted CA
   - Hostname mismatch
   - Self-signed certificate
   - Revoked certificate
   - Weak signature algorithm (SHA-1)
   - Invalid certificate chain
2. Navigate to each error scenario and document browser UI response
3. Verify that warning messages clearly communicate security risk
4. Test that warnings are difficult to bypass (require explicit user action)
5. Evaluate warning message clarity for non-technical users
6. Test that technical details are available (certificate viewer)
7. Verify that bypass actions are clearly labeled with risk warnings
8. Test mobile and desktop warning UI differences
9. Verify that errors are logged in browser console
10. Certificate errors trigger full-page interstitial warnings
11. Warning messages clearly explain the security risk
12. Users should take explicit action to bypass (not easy clickthrough)
13. Technical details are accessible via "Advanced" or similar link
14. Certificate details can be viewed and inspected
15. Warning UI uses appropriate visual indicators (red, warning icons)
16. Bypass options are clearly labeled with risk warnings
17. Error types are distinguishable in UI messages
18. Console logs provide technical error details

**Pass Criteria**: All certificate errors display prominent warnings AND bypass requires explicit user acknowledgment of risk

**Fail Criteria**: Certificate errors can be bypassed silently OR warnings are unclear or easily dismissed

**Evidence**: Screenshots of warning UI for each error type, user testing feedback on clarity, console error logs, comparison with browser security UI guidelines

**References**: