EN-304-617_v0.0.4.md

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

- Google Transparency Report - HTTPS Security: https://transparencyreport.google.com/https/overview

### Assessment: ENC-REQ-16 (HTTPS-first mode)

**Reference**: ENC-REQ-16 - Browser shall implement HTTPS-first mode to automatically upgrade HTTP connections to HTTPS when available

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

**Task**: Verify that HTTPS-first mode protects users from accidental insecure connections where attackers perform SSL-stripping attacks to downgrade HTTPS to HTTP, enabling interception of credentials and session tokens. Automatic HTTPS upgrade eliminates the window of vulnerability before secure connections are established, while user warnings for HTTP-only sites ensure informed consent before transmitting data over insecure channels.

**Verification**:

1. Enable HTTPS-first mode in browser settings
2. Navigate to HTTP URLs of sites that support HTTPS (http://example.com)
3. Verify that browser automatically upgrades to HTTPS
4. Test fallback behavior when HTTPS is unavailable:
   - Site doesn't support HTTPS
   - HTTPS connection fails/times out
   - Certificate error on HTTPS version
5. Verify user is prompted before loading HTTP-only sites
6. Test HTTPS upgrade for embedded resources (images, scripts, iframes)
7. Test interaction with HSTS and upgrade-insecure-requests
8. Measure performance impact of HTTPS upgrade attempts
9. Test HTTPS-first with different types of navigation (typed URL, bookmarks, links)
10. Verify browser remembers HTTP-only sites to avoid repeated upgrade attempts
11. HTTP URLs are automatically upgraded to HTTPS
12. Address bar shows HTTPS protocol after upgrade
13. Fallback to HTTP works with user consent when HTTPS unavailable
14. User is warned before loading HTTP-only sites
15. Browser remembers HTTP-only sites (cache/allowlist)
16. Embedded resources are also upgraded
17. HTTPS-first works alongside HSTS
18. Network panel shows upgrade attempts
19. Performance impact is minimal (parallel attempts)

**Pass Criteria**: HTTP connections are automatically upgraded to HTTPS when available AND users are warned before HTTP-only sites load

**Fail Criteria**: HTTP URLs are not upgraded OR no warnings for HTTP-only sites OR fallback doesn't work

**Evidence**: Network logs showing HTTP to HTTPS upgrades, address bar screenshots, warning dialog screenshots, performance measurements, browser settings showing HTTPS-first configuration

**References**:

- Chrome HTTPS-First Mode: https://blog.chromium.org/2021/07/increasing-https-adoption.html
- Firefox HTTPS-Only Mode: https://support.mozilla.org/en-US/kb/https-only-prefs
- HTTPS Upgrade Mechanisms: https://www.w3.org/TR/upgrade-insecure-requests/
- EFF HTTPS Everywhere: https://www.eff.org/https-everywhere
- OWASP Transport Layer Protection: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

### Assessment: ENC-REQ-17 (Certificate pinning bypass detection)

**Reference**: ENC-REQ-17 - Browser shall detect and prevent attempts to bypass certificate pinning protections

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

**Task**: Verify that certificate pinning bypass detection prevents attackers or malware from installing rogue root certificates to perform man-in-the-middle attacks against pinned domains. Detecting bypass attempts protects browser vendor properties and high-security sites from SSL interception, while logging and user warnings ensure transparency when certificate validation is weakened by enterprise policies or security tools.

**Verification**:

1. Configure test environment with certificate pinning enabled
2. Attempt various bypass techniques:
   - Installing custom root CA certificates
   - Using SSL/TLS interception proxies (corporate MITM)
   - Modifying browser certificate store
   - Using browser extensions to disable pinning
   - Command-line flags to disable certificate validation
3. Test browser's built-in static pins (Google, Mozilla properties)
4. Verify that pin bypass attempts are detected and logged
5. Test enterprise policy controls for pinning exceptions
6. Verify user notifications for certificate store modifications
7. Test that developer tools can't silently bypass pinning
8. Examine browser internal state for pin enforcement
9. Test interaction between pin bypass and security indicators
10. Static pins for built-in domains cannot be bypassed
11. Custom root CA installation triggers user warnings
12. SSL interception is detected and indicated in UI
13. Browser logs pin bypass attempts
14. Certificate store modifications are visible to users
15. Enterprise policies can override pins with explicit configuration
16. Developer tools respect pinning (or show clear bypass warnings)
17. Security indicators reflect weakened security when pins bypassed
18. Console logs show certificate validation details

**Pass Criteria**: Static certificate pins cannot be bypassed without explicit user/admin action AND pin bypass attempts are logged and indicated

**Fail Criteria**: Pins can be silently bypassed OR no indication when certificate validation is weakened

**Evidence**: Console logs showing pin enforcement, certificate store modification warnings, test results from bypass attempts, enterprise policy documentation, security indicator screenshots

**References**:

- Chrome Certificate Pinning: https://www.chromium.org/Home/chromium-security/education/tls/
- OWASP Certificate Pinning: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- SSL Interception Detection: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
- Mozilla Pin Override: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning

### Assessment: ENC-REQ-18 (TLS downgrade protection)

**Reference**: ENC-REQ-18 - Browser shall implement protections against TLS version and cipher suite downgrade attacks

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

**Task**: Verify that TLS downgrade protection prevents man-in-the-middle attackers from forcing browsers to use older TLS versions or weaker cipher suites with known vulnerabilities like POODLE or BEAST. Downgrade protection ensures that even when attackers intercept and modify handshake messages, the browser detects the manipulation and aborts the connection rather than proceeding with weakened cryptographic parameters.

**Verification**:

1. Set up test environment capable of simulating man-in-the-middle attacks
2. Configure server supporting TLS 1.3 and TLS 1.2
3. Attempt to force downgrade from TLS 1.3 to TLS 1.2 by manipulating ClientHello
4. Test TLS_FALLBACK_SCSV signaling value (RFC 7507)
5. Attempt downgrade attacks during connection:
   - Version rollback to older TLS versions
   - Cipher suite downgrade to weaker algorithms
   - Extension stripping attacks
6. Verify browser detects and rejects downgrade attempts
7. Test that Finished message MAC includes all handshake messages
8. Verify TLS 1.3 downgrade protection sentinel values in ServerHello.random
9. Test protection against truncation attacks
10. Browser signals maximum supported TLS version correctly
11. TLS_FALLBACK_SCSV is included in fallback connections
12. Version rollback attacks are detected and connection aborted
13. Cipher suite downgrade attempts trigger handshake failure
14. Browser validates ServerHello.random for downgrade sentinels
15. Extension stripping is detected through transcript hash validation
16. Finished message properly authenticates handshake
17. Console shows error messages for detected downgrade attempts
18. Connection fails securely rather than completing with weakened security

**Pass Criteria**: All TLS downgrade attempts are detected AND connections fail rather than proceed with weakened security

**Fail Criteria**: Any downgrade attack succeeds OR browser accepts weakened connection parameters

**Evidence**: Packet captures showing downgrade attempts and rejection, Wireshark showing TLS_FALLBACK_SCSV, console error logs, test scripts demonstrating attack attempts

**References**:

- RFC 7507 - TLS Fallback SCSV: https://datatracker.ietf.org/doc/html/rfc7507
- RFC 8446 - TLS 1.3 Downgrade Protection: https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3
- POODLE Attack and Downgrade Prevention: https://www.openssl.org/~bodo/ssl-poodle.pdf
- Chrome TLS Implementation: https://www.chromium.org/Home/chromium-security/education/tls/

### Assessment: ENC-REQ-19 (Legacy crypto deprecation)

**Reference**: ENC-REQ-19 - Browser shall deprecate and remove support for legacy cryptographic algorithms and protocols

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

**Task**: Verify that legacy crypto deprecation prevents attackers from exploiting known cryptographic weaknesses in outdated algorithms like SHA-1 collision attacks, RC4 biases, or short RSA key factorization. Progressive deprecation with clear timelines gives organizations migration paths while ensuring browsers eventually reject severely compromised cryptography that no longer provides meaningful security guarantees.

**Verification**:

1. Test browser behavior with legacy cryptographic elements:
   - TLS 1.0 and TLS 1.1 protocols
   - SHA-1 certificates
   - 1024-bit RSA keys
   - MD5-based signatures
   - RC4 cipher suite
   - CBC-mode cipher suites
   - DSA certificates
2. Verify that legacy protocols/algorithms are rejected or trigger warnings
3. Test deprecation timeline (when were features removed)
4. Verify that browser update notes document deprecated features
5. Test enterprise policy overrides for legacy support (temporary exceptions)
6. Check browser developer documentation for deprecation roadmap
7. Test fallback behavior when modern crypto unavailable
8. Verify that critical errors can't be bypassed for severely deprecated crypto
9. TLS 1.0 and 1.1 connections are rejected or show warnings
10. SHA-1 certificates trigger security errors
11. 1024-bit RSA keys are rejected
12. MD5 and RC4 are completely disabled
13. Legacy crypto rejections show clear error messages
14. Browser documentation lists deprecated features with timelines
15. Enterprise policies can temporarily enable legacy support (if necessary)
16. No silent fallback to insecure legacy protocols
17. Console logs indicate when legacy crypto is encountered

**Pass Criteria**: All severely deprecated cryptographic elements are rejected AND users are warned about moderately deprecated features

**Fail Criteria**: Legacy crypto is accepted without warnings OR deprecated features work without indication

**Evidence**: Connection error screenshots for legacy servers, browser release notes documenting deprecations, console error logs, test results across browser versions showing deprecation timeline

**References**:

- Chrome Deprecation Timeline: https://www.chromium.org/Home/chromium-security/education/tls/
- Mozilla Security Roadmap: https://wiki.mozilla.org/Security/Server_Side_TLS
- RFC 8996 - Deprecating TLS 1.0 and TLS 1.1: https://datatracker.ietf.org/doc/html/rfc8996
- CA/B Forum - SHA-1 Deprecation: https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/
- NIST Cryptographic Algorithm Deprecation: https://csrc.nist.gov/projects/hash-functions

### Assessment: ENC-REQ-20 (Cryptographic key isolation)

**Reference**: ENC-REQ-20 - Browser shall isolate cryptographic keys and prevent cross-origin key access

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

**Task**: Verify that cryptographic key isolation enforces same-origin policy for Web Crypto API keys, preventing malicious cross-origin scripts from accessing or exfiltrating cryptographic keys generated by other origins. Key isolation ensures that even if an attacker compromises one origin, they cannot steal cryptographic keys belonging to other origins to impersonate users or decrypt sensitive data protected by those keys.

**Verification**:

1. Create test scenarios with Web Crypto API key generation on different origins
2. Generate cryptographic keys on https://origin-a.com using Web Crypto API
3. Attempt to access keys from https://origin-b.com
4. Test IndexedDB key storage isolation across origins
5. Verify that keys marked as non-extractable cannot be extracted
6. Test key export restrictions based on key usage
7. Test that key handles cannot be passed between origins via postMessage
8. Verify key isolation in browser's internal key storage
9. Test hardware-backed key storage (if available, e.g., WebAuthn)
10. Test key isolation for different user profiles/contexts
11. Keys generated on one origin cannot be accessed from another origin
12. IndexedDB key storage respects same-origin policy
13. Non-extractable keys cannot be exported or extracted
14. Key usage restrictions are enforced (keys can't be used for unauthorized operations)
15. Key handles are opaque and cannot be transferred cross-origin
16. Browser internal key storage is isolated per origin
17. Hardware-backed keys are protected by platform security
18. Different user profiles have separate key storage
19. Attempts to access cross-origin keys throw SecurityError

**Pass Criteria**: Cryptographic keys are strictly isolated by origin AND non-extractable keys cannot be exported

**Fail Criteria**: Keys can be accessed across origins OR key usage restrictions can be bypassed

**Evidence**: Console logs showing SecurityError for cross-origin key access, test code demonstrating isolation, browser internal state showing key storage separation, WebAuthn test results

**References**:

- W3C Web Cryptography API - Key Storage: https://www.w3.org/TR/WebCryptoAPI/#concepts-key-storage
- MDN CryptoKey: https://developer.mozilla.org/en-US/docs/Web/API/CryptoKey
- Chrome Web Crypto Key Isolation: https://chromium.googlesource.com/chromium/src/+/master/components/webcrypto/README.md
- OWASP Key Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
- WebAuthn Specification - Credential Storage: https://www.w3.org/TR/webauthn-2/#credential-storage

### Assessment: ENC-REQ-21 (Certificate store security)

**Reference**: ENC-REQ-21 - Browser shall maintain secure certificate store with integrity protection and auditing

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

**Task**: Verify that certificate store security prevents attackers from installing rogue root certificates to enable man-in-the-middle attacks against all TLS connections. Protected certificate stores with integrity checking and audit trails detect unauthorized modifications, while requiring explicit user consent for root CA changes prevents malware from silently compromising the foundation of TLS trust.

**Verification**:

1. Examine browser's certificate store location and access controls
2. Test that certificate store is protected with appropriate file system permissions
3. Attempt to modify certificate store while browser is running
4. Verify that certificate store changes are logged/auditable
5. Test root CA certificate management:
   - View installed root certificates
   - Add custom root CA (with user consent)
   - Remove root CA (with user consent)
   - Verify certificate trust settings
6. Test that system certificate store is used appropriately
7. Verify that enterprise-managed certificates are clearly indicated
8. Test certificate store integrity verification mechanisms
9. Test that certificate store updates are secure and authenticated
10. Verify user notifications for certificate store modifications
11. Certificate store files have restrictive permissions (not world-readable)
12. Certificate store cannot be modified without appropriate privileges
13. Browser detects and handles certificate store corruption
14. Root CA additions/removals require explicit user consent
15. Certificate store UI shows all installed root certificates
16. System certificate store integration works correctly
17. Enterprise-managed certificates are visibly marked
18. Certificate store modifications are logged
19. Users are notified of certificate store changes
20. Certificate store updates are signed and verified

**Pass Criteria**: Certificate store is protected with appropriate access controls AND modifications require user consent and are logged

**Fail Criteria**: Certificate store can be modified without user knowledge OR no audit trail for modifications

**Evidence**: File system permission analysis, certificate store UI screenshots, audit log samples, test results from modification attempts, enterprise policy documentation

**References**:

- Mozilla Root Store Program: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
- Chrome Root Store: https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/
- Microsoft Trusted Root Program: https://learn.microsoft.com/en-us/security/trusted-root/program-requirements
- Apple Root Certificate Program: https://www.apple.com/certificateauthority/ca_program.html
- OWASP Certificate Management: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#certificate-and-public-key-pinning

### Assessment: ENC-REQ-22 (Certificate pinning override prohibition)

**Reference**: ENC-0-REQ-22 - Browser shall not allow user override of certificate pinning failures

**Given**: A conformant browser with ENC-0 capability (full encryption with HSM support)

**Task**: Verify that the browser prohibits user override of certificate pinning failures to prevent users from being socially engineered into accepting fraudulent certificates, ensuring that pinning violations - which indicate active man-in-the-middle attacks or certificate misissuance - are treated as hard failures that cannot be bypassed, protecting high-security environments where certificate pinning is a critical defense against targeted attacks on specific domains.

**Verification**:

1. Configure test server with certificate pinning via HTTP header or browser built-in pins
2. Establish baseline connection to verify pinning is active
3. Modify server certificate to trigger pinning violation:
   - Use different certificate authority
   - Use expired pin
   - Use self-signed certificate
   - Use certificate from wrong domain
4. Attempt to connect to server with pinning violation
5. Verify that browser blocks connection with clear error message
6. Verify that no "proceed anyway" or "add exception" option is available
7. Test that advanced settings do not provide override mechanism
8. Verify that enterprise policies cannot disable pinning for pinned domains
9. Test that developer tools cannot bypass pinning enforcement
10. Verify that command-line flags cannot disable pinning
11. Test that error message explains pinning failure clearly
12. Verify that pinning failures are logged for security monitoring
13. Test that users are directed to contact site administrators, not bypass warnings

**Pass Criteria**: Pinning failures cannot be overridden through any mechanism AND no bypass options exist in UI OR settings AND error messages explain pinning violations AND failures are logged

**Fail Criteria**: Users can bypass pinning failures OR override mechanisms exist OR pinning can be disabled for pinned domains OR unclear error messages

**Evidence**: Pinning violation error screenshots showing no bypass option, settings inspection showing no override controls, policy test results, developer tools verification, log entries showing pinning failures

**References**:

- HTTP Public Key Pinning: https://www.rfc-editor.org/rfc/rfc7469
- Certificate Pinning Best Practices: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- CWE-295: Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html

### Assessment: ENC-REQ-23 (Hardware-backed cryptographic operations)

**Reference**: ENC-0-REQ-23 - All cryptographic operations shall be performed in hardware-backed secure enclaves when available

**Given**: A conformant browser with ENC-0 capability on hardware with secure enclave support

**Task**: Verify that all cryptographic operations utilize hardware-backed secure enclaves (such as TPM, Secure Enclave, or TEE) when available, ensuring that private keys and sensitive cryptographic material never exist in unencrypted form in main memory, protecting against memory dumps, cold boot attacks, and malware that attempts to extract cryptographic keys from software-based key storage, providing defense-in-depth through hardware isolation.

**Verification**:

1. Identify available hardware security features on test platform:
   - TPM (Trusted Platform Module) on Windows/Linux
   - Secure Enclave on macOS/iOS
   - TEE (Trusted Execution Environment) on Android
   - Hardware security modules (HSM)
2. Install browser on platform with hardware security support
3. Verify that browser detects and initializes hardware security features
4. Perform cryptographic operations requiring key generation or usage:
   - TLS client certificates
   - Web Crypto API key generation
   - Password manager encryption keys
   - Browser sync encryption keys
5. Verify that keys are generated and stored in hardware-backed storage
6. Test that private keys cannot be exported from hardware storage
7. Verify that cryptographic operations occur within secure enclave
8. Test that key material is not accessible via memory dumps
9. Verify that browser preferences or about page indicates hardware security status
10. Test that browser falls back gracefully if hardware security is unavailable
11. Verify that enterprise policies can require hardware-backed crypto
12. Test that hardware security failures are logged and reported to users

**Pass Criteria**: Cryptographic operations use hardware-backed storage when available AND private keys are non-exportable AND key material is protected from memory access AND hardware security status is visible to users

**Fail Criteria**: Keys are stored in software despite hardware availability OR keys can be exported OR no hardware security detection OR silent fallback without user notification

**Evidence**: Platform security feature verification, key storage location inspection, memory dump analysis showing no key exposure, browser status page screenshots, enterprise policy configuration tests

**References**:

- Trusted Platform Module: https://trustedcomputinggroup.org/resource/tpm-library-specification/
- Web Crypto API Key Storage: https://www.w3.org/TR/WebCryptoAPI/#concepts-key-storage
- Hardware Security Modules: https://csrc.nist.gov/glossary/term/hardware_security_module

### Assessment: ENC-REQ-24 (Encryption strictness configuration)

**Reference**: ENC-2-REQ-17 - Users shall be able to configure encryption strictness levels

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

**Task**: Verify that users can configure encryption strictness levels to balance security requirements with compatibility needs, enabling organizations and advanced users to enforce stricter encryption policies than defaults (such as TLS 1.3-only, strong cipher suites only, or mandatory HSTS) or relax policies for specific legitimate scenarios (such as internal legacy systems), providing flexibility while maintaining security visibility and audit trails.

**Verification**:

1. Access browser encryption settings or configuration interface
2. Identify available encryption strictness options:
   - Minimum TLS version selection (TLS 1.2, TLS 1.3 only)
   - Cipher suite policy (strong only, compatible, allow weak)
   - Mixed content policy (block all, block active only, allow)
   - Certificate validation strictness (strict, standard, permissive)
   - HSTS enforcement level
3. Test configuring each strictness level and verify enforcement:
   - Set TLS 1.3-only mode and verify TLS 1.2 connections fail
   - Configure strong cipher suites only and verify weak cipher rejection
   - Enable strict mixed content blocking and verify all mixed content blocked
   - Set strict certificate validation and verify self-signed cert rejection
4. Verify that strictness changes take effect immediately or after restart
5. Test that configuration changes are persistent across browser sessions
6. Verify that enterprise policies can override user strictness settings
7. Test that per-site exceptions can be configured for compatibility
8. Verify that strictness level changes are logged
9. Test that current strictness level is visible in security indicators
10. Verify that documentation explains security implications of each level
11. Test that strictness cannot be weakened below secure baseline without warnings

**Pass Criteria**: Multiple encryption strictness levels are available AND configuration changes are enforced AND settings persist AND per-site exceptions are possible AND changes are logged

**Fail Criteria**: No strictness configuration available OR changes not enforced OR settings don't persist OR no audit trail OR no security baseline

**Evidence**: Settings UI screenshots showing strictness options, connection test results at different levels, persistence verification, per-site exception demonstrations, audit logs

**References**:

- TLS Configuration Recommendations: https://wiki.mozilla.org/Security/Server_Side_TLS
- OWASP Transport Layer Protection: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

### Assessment: ENC-REQ-25 (Connection security visual indicators)

**Reference**: ENC-2-REQ-18 - Browser shall provide visual indicators for connection security status

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

**Task**: Verify that the browser provides clear, prominent visual indicators for connection security status, enabling users to quickly identify secure HTTPS connections, insecure HTTP connections, and connection security issues, preventing users from entering sensitive information on insecure sites and helping users recognize potential man-in-the-middle attacks or certificate problems through consistent, understandable security indicators in the browser UI.

**Verification**:

1. Navigate to various sites with different security states:
   - Valid HTTPS with strong encryption (https://example.com with TLS 1.3)
   - Valid HTTPS with weak encryption (https://site.com with TLS 1.2, weak cipher)
   - HTTP site (http://insecure.com)
   - HTTPS with certificate error (expired, self-signed, wrong domain)
   - HTTPS with mixed content (active and passive)
   - HTTPS with Extended Validation certificate
2. Verify that each security state has distinct visual indicator:
   - Padlock icon or security indicator in address bar
   - Color coding (green for secure, red for insecure, warning for issues)
   - Text labels ("Secure", "Not Secure", "Connection is not secure")
   - Icon states (locked, unlocked, warning symbol)
3. Test that clicking security indicator shows detailed connection information:
   - TLS version and cipher suite
   - Certificate details and validity
   - Mixed content warnings
   - Permission grants
4. Verify that indicators are visible in all browser UI states (fullscreen, focus mode, etc.)
5. Test that indicators cannot be spoofed by web content
6. Verify that security indicator changes are immediate upon navigation
7. Test that security indicators are accessible (screen reader compatible)
8. Verify that indicators follow consistent design across all platforms
9. Test that users can easily distinguish secure from insecure connections
10. Verify that connection security details are easy to access
11. Test that security indicators work in private/incognito mode

**Pass Criteria**: Distinct visual indicators for each security state AND indicators are prominent and clear AND detailed information is accessible AND indicators cannot be spoofed AND consistent across platforms

**Fail Criteria**: Security indicators are unclear OR states are not visually distinct OR detailed information not available OR indicators can be spoofed OR inconsistent across platforms

**Evidence**: Screenshots of security indicators for each connection state, detailed security info panel screenshots, accessibility testing results, spoofing attempt tests, cross-platform consistency verification

**References**:

- Browser Security Indicators: https://www.w3.org/TR/design-principles/#priority-of-constituencies
- User Security Awareness: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt

### Assessment: ENC-REQ-26 (User encryption settings control)

**Reference**: ENC-3-REQ-11 - Users shall have full control over encryption settings

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that users have full control over all encryption settings, enabling advanced users and specific deployment scenarios to configure encryption behavior according to their unique requirements, such as enabling legacy protocols for compatibility with older systems, configuring custom cipher suite preferences, or managing certificate exceptions, while ensuring that users are informed of the security implications of relaxing encryption requirements.

**Verification**:

1. Access browser advanced encryption settings
2. Verify that comprehensive encryption controls are available:
   - TLS version selection (TLS 1.0, 1.1, 1.2, 1.3)
   - Individual cipher suite enable/disable
   - Certificate validation options
   - Mixed content policy configuration
   - HSTS bypass capabilities
   - Certificate exception management
   - Revocation checking options
3. Test modifying each encryption setting:
   - Enable legacy TLS 1.0/1.1 and verify older servers accessible
   - Disable specific cipher suites and verify negotiation changes
   - Relax certificate validation and verify self-signed cert acceptance
   - Allow mixed content and verify passive content loads
   - Add certificate exceptions and verify accepted
4. Verify that each setting change shows security warning explaining risks
5. Test that changes require user acknowledgment of risks
6. Verify that current encryption configuration is clearly documented in UI
7. Test that dangerous configurations trigger prominent warnings
8. Verify that encryption settings can be exported/imported for consistency
9. Test that enterprise policies can restrict user control over specific settings
10. Verify that reset-to-defaults option exists for safe rollback
11. Test that encryption setting changes are logged
12. Verify that help documentation explains each setting clearly

**Pass Criteria**: All encryption settings are user-configurable AND security warnings accompany risky changes AND current configuration is visible AND reset option exists AND changes are logged

**Fail Criteria**: Encryption settings are not configurable OR no security warnings for risky changes OR configuration not visible OR no rollback option OR no audit trail

**Evidence**: Advanced settings UI screenshots, configuration change workflows, security warning examples, setting export/import tests, policy restriction demonstrations, audit logs

**References**:

- TLS Configuration: https://wiki.mozilla.org/Security/Server_Side_TLS
- User Control Principles: https://www.w3.org/TR/design-principles/#user-control

### Assessment: ENC-REQ-27 (Encryption status UI indicators)

**Reference**: ENC-3-REQ-12 - Browser shall provide encryption status indicators in UI

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that the browser provides comprehensive encryption status indicators throughout the user interface, enabling users to understand the current encryption configuration and connection security state at any time, helping users make informed decisions about whether their current settings are appropriate for their security needs and alerting them to potential security issues that may result from configuration changes.

**Verification**:

1. Access browser with various encryption configurations active
2. Verify that encryption status is visible in multiple UI locations:
   - Address bar security indicator
   - Settings page encryption section
   - About/information pages
   - Developer tools security panel
3. Test that status indicators show:
   - Current TLS version in use
   - Active cipher suite
   - Certificate validity status
   - Enabled/disabled encryption features (HSTS, CT, OCSP)
   - Legacy protocol status (if enabled)
   - Number of certificate exceptions
4. Navigate to sites with different security configurations
5. Verify that indicators update dynamically to reflect current connection
6. Test that clicking indicators provides detailed encryption information
7. Verify that weak encryption configurations trigger visual warnings
8. Test that encryption status persists in browser session info
9. Verify that status indicators are accessible via keyboard navigation
10. Test that indicators work in all browsing modes (normal, private, reader)
11. Verify that encryption dashboard or summary page exists
12. Test that status information is exportable for security audits

**Pass Criteria**: Encryption status visible in multiple UI locations AND indicators show detailed configuration AND indicators update dynamically AND weak configurations trigger warnings AND status is exportable

**Fail Criteria**: Encryption status not visible OR indicators lack detail OR no dynamic updates OR no warnings for weak config OR status not exportable

**Evidence**: UI screenshots from various locations showing status, status detail panel captures, dynamic update demonstrations, weak config warning examples, audit export samples

**References**:

- Security Indicators Design: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Transparency in Browser Security: https://www.w3.org/TR/design-principles/#transparency

### Assessment: ENC-REQ-28 (Legacy protocol compatibility mode)

**Reference**: ENC-3-REQ-13 - Legacy protocol support may be enabled for compatibility with user consent

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that legacy protocol support (SSL 3.0, TLS 1.0, TLS 1.1) can be enabled for compatibility with older systems when necessary, but requires explicit, informed user consent with clear security warnings, ensuring users understand the risks of downgrading to deprecated protocols while enabling access to legacy systems that cannot be immediately upgraded, such as embedded devices, industrial control systems, or archived services.

**Verification**:

1. Verify that legacy protocols are disabled by default
2. Attempt to connect to server requiring legacy protocol (TLS 1.0 or TLS 1.1)
3. Verify that connection fails with clear error message explaining protocol version mismatch
4. Access browser settings to enable legacy protocol support
5. Verify that enabling legacy protocols requires:
   - Navigation to advanced settings section
   - Explicit checkbox or toggle action
   - Acknowledgment of security warning dialog
6. Test that security warning clearly explains:
   - Legacy protocols have known vulnerabilities
   - Connections may be susceptible to downgrade attacks
   - Sensitive information should not be transmitted
   - Recommendation to upgrade server instead
7. Verify that legacy protocol enablement is persistent across sessions
8. Test that legacy protocol usage triggers visual indicator in address bar
9. Verify that connections using legacy protocols show prominent warning
10. Test that legacy protocol can be enabled for specific sites only (not globally)
11. Verify that legacy protocol enablement is logged for security auditing
12. Test that reset to defaults disables legacy protocols

**Pass Criteria**: Legacy protocols disabled by default AND enablement requires explicit consent AND clear security warnings shown AND usage is indicated visually AND site-specific enablement possible AND changes logged

**Fail Criteria**: Legacy protocols enabled by default OR no consent required OR warnings unclear OR no visual indicators OR only global enablement OR no audit trail

**Evidence**: Default protocol test results, enablement workflow screenshots, security warning content, visual indicator examples, site-specific configuration tests, audit log samples

**References**:

- Deprecating Legacy TLS: https://datatracker.ietf.org/doc/rfc8996/
- TLS 1.0 and 1.1 Deprecation: https://www.rfc-editor.org/info/rfc8996

### Assessment: ENC-REQ-29 (Complete encryption policy control)

**Reference**: ENC-4-REQ-6 - Users shall have complete control over all encryption policies

**Given**: A conformant browser with ENC-4 capability (minimal encryption)

**Task**: Verify that users have unrestricted control over all encryption policies without artificial limitations, enabling specialized use cases such as security research, penetration testing, legacy system maintenance, or air-gapped environments where standard encryption enforcement may need to be completely disabled, while ensuring that the browser clearly indicates when insecure configurations are active and the risks associated with completely disabling encryption protections.

**Verification**:

1. Access all available encryption policy controls in browser
2. Verify that users can modify every encryption-related setting:
   - Completely disable TLS/SSL enforcement
   - Allow HTTP for all connections
   - Disable all certificate validation
   - Accept any cipher suite including export-grade
   - Disable HSTS, OCSP, CT, and all security features
   - Allow unlimited certificate exceptions
   - Disable mixed content blocking entirely
   - Remove all protocol version restrictions
3. Test disabling each encryption protection individually
4. Verify that disabled protections do not activate even in dangerous scenarios
5. Test that completely insecure configuration allows access to test servers:
   - HTTP-only servers
   - Self-signed certificate servers
   - Expired certificate servers
   - Weak cipher servers (3DES, RC4)
6. Verify that browser displays persistent warning when encryption is disabled
7. Test that insecure configuration status is highly visible in all UI
8. Verify that browser warns before entering sensitive input on insecure connections
9. Test that configuration can be saved and restored
10. Verify that no enterprise policies can override user's complete control
11. Test that security researchers can use browser for SSL/TLS testing
12. Verify that documentation explains appropriate use cases for insecure configs

**Pass Criteria**: All encryption policies are user-modifiable without restriction AND disabled protections do not activate AND insecure status is highly visible AND configuration is persistent AND appropriate for specialized use cases

**Fail Criteria**: Some encryption policies cannot be disabled OR disabled protections still activate OR insecure status not visible OR configuration doesn't persist OR inappropriate for intended use cases

**Evidence**: Complete settings access screenshots, disabled protection test results, insecure configuration visual indicators, specialized use case demonstrations, security researcher testimonials

**References**:

- Security Research Ethics: https://www.w3.org/Security/wiki/Improving_Web_Security
- Penetration Testing Requirements: https://owasp.org/www-community/Penetration_testing

### Assessment: ENC-REQ-30 (User-enabled legacy protocol support)

**Reference**: ENC-4-REQ-7 - Browser shall support legacy protocols when explicitly enabled by user

**Given**: A conformant browser with ENC-4 capability (minimal encryption)

**Task**: Verify that browser supports legacy cryptographic protocols (SSL 3.0, TLS 1.0, TLS 1.1) when explicitly enabled by user, ensuring that legacy systems, embedded devices, or historical services that cannot be upgraded remain accessible through modern browsers in specialized scenarios, while making it clear that these protocols have known security vulnerabilities and should only be used when absolutely necessary with full understanding of the risks.

**Verification**:

1. Access browser protocol version settings
2. Verify that legacy protocol options are available:
   - SSL 3.0 enable/disable
   - TLS 1.0 enable/disable
   - TLS 1.1 enable/disable
3. Enable each legacy protocol individually
4. Test connection to servers requiring each legacy protocol:
   - SSL 3.0-only server (if available for testing)
   - TLS 1.0-only server
   - TLS 1.1-only server
5. Verify that connections succeed when protocol is enabled
6. Verify that connections fail when protocol is disabled
7. Test that protocol negotiation prefers newest enabled version
8. Verify that legacy protocol connections show security warnings
9. Test that mixed protocol versions work correctly (e.g., TLS 1.0 and 1.3 both enabled)
10. Verify that legacy protocol usage is logged
11. Test that browser identifies which protocol version was used for each connection
12. Verify that legacy protocol support can be toggled without browser restart
13. Test that documentation explains security risks of each legacy protocol

**Pass Criteria**: All legacy protocols can be enabled by user AND enabled protocols function correctly AND protocol negotiation works properly AND legacy usage is warned and logged AND risks are documented

**Fail Criteria**: Legacy protocols cannot be enabled OR enabled protocols don't work OR protocol negotiation fails OR no warnings/logging OR risks not explained

**Evidence**: Legacy protocol enablement screenshots, successful connection tests to legacy servers, protocol version negotiation logs, security warning examples, risk documentation excerpts

**References**:

- SSL 3.0 Vulnerabilities (POODLE): https://www.rfc-editor.org/rfc/rfc7568
- TLS 1.0 and 1.1 Deprecation: https://datatracker.ietf.org/doc/rfc8996/
- Legacy Protocol Security Risks: https://www.nist.gov/publications/transitioning-use-cryptographic-algorithms-and-key-lengths

## 6.4 Security Event Logging Assessments

This section covers assessment procedures for requirements LOG-REQ-1 through LOG-REQ-20, addressing security event logging, audit trails, privacy-preserving telemetry, log retention, and security monitoring capabilities.

### Assessment: LOG-REQ-1 (Security event logging)

**Reference**: LOG-REQ-1 - Browser shall implement comprehensive security event logging for security-relevant events

**Given**: A conformant browser with LOG-1 or higher capability

**Task**: Verify that comprehensive security event logging enables detection and investigation of attacks, providing audit trails for security incidents like XSS attempts, CSP violations, and CORS bypasses. Complete logging with timestamps, origins, and outcomes allows security teams to identify attack patterns, correlate events across multiple targets, and respond to threats effectively while supporting compliance with security monitoring requirements.

**Verification**:

1. Configure the browser to enable security event logging in developer or enterprise mode
2. Access the browser's internal logging interfaces (chrome://net-internals/#events, about:networking, or equivalent)
3. Navigate to a test page that triggers multiple security events (mixed content, certificate errors, XSS attempts)
4. Attempt cross-origin requests that violate CORS policies
5. Load test pages with Content Security Policy violations
6. Trigger sandbox violations by attempting to access restricted APIs
7. Review the logged events to verify all security-relevant actions are captured
8. Export the security event log to verify it contains timestamps, event types, origins, and outcomes
9. Verify that security events include sufficient context for investigation (URL, origin, error type, timestamp)
10. Test that security events persist across browser restarts if configured for persistent logging
11. All security policy violations are logged with accurate timestamps
12. Logs include sufficient context to identify the origin and nature of security events
13. Security events include: CSP violations, CORS failures, mixed content blocks, certificate errors, sandbox violations
14. Logs distinguish between blocked and allowed actions with clear outcomes
15. Event log format is structured and machine-readable (JSON or similar)
16. Logs can be exported for analysis or forwarding to external systems

**Pass Criteria**: All tested security events are captured in logs with complete context (timestamp, origin, event type, outcome) AND logs are exportable in a structured format

**Fail Criteria**: Any security event fails to be logged OR logs lack critical context (timestamp, origin, or outcome) OR logs are not exportable

**Evidence**: Screenshots of security event logs showing various event types, exported log files in JSON/structured format, video recordings of security events being triggered and logged, comparison matrices showing event coverage

**References**:

- W3C Reporting API: https://www.w3.org/TR/reporting-1/
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- NIST SP 800-92 Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final

### Assessment: LOG-REQ-2 (Certificate error logging)

**Reference**: LOG-REQ-2 - Browser shall log all certificate validation failures with detailed error information

**Given**: A conformant browser with LOG-1 or higher capability

**Task**: Verify that certificate error logging enables detection of man-in-the-middle attacks and certificate misconfigurations, providing detailed information for security investigations. Comprehensive certificate logs with chain details, error types, and revocation status help identify patterns of TLS interception, rogue certificates, or systematic validation failures that could indicate ongoing attacks against users or infrastructure.

**Verification**:

1. Set up a test web server with various certificate issues (expired, self-signed, wrong hostname, revoked)
2. Navigate to https://expired.badssl.com/ and verify the certificate error is logged
3. Navigate to https://wrong.host.badssl.com/ and verify hostname mismatch is logged
4. Navigate to https://self-signed.badssl.com/ and verify self-signed certificate is logged
5. Navigate to https://revoked.badssl.com/ and verify revocation status is logged
6. Review the certificate error logs to verify they include: certificate chain, error type, validation date, origin
7. Test certificate pinning failures by creating a pinning policy and violating it
8. Verify that certificate transparency failures are logged when CT enforcement is enabled
9. Test that HSTS violations involving certificates are properly logged
10. All certificate validation failures are logged with specific error codes
11. Logs include certificate subject, issuer, validity period, and error reason