EN-304-617.md

**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 → Verify that TLS 1.3 cipher suites are properly supported (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256)
2. Navigate the browser to each server endpoint and capture the TLS handshake using packet capture tools (Wireshark, tcpdump) → Confirm that browser successfully negotiates TLS 1.3 when server supports it
3. Verify that the browser successfully negotiates TLS 1.3 when available → Verify that TLS 1.3 is preferred over TLS 1.2 when both are available
4. Configure the server to offer only TLS 1.3 and verify successful connection → Check that browser Security panel shows "TLS 1.3" as the protocol version
5. Test TLS 1.3 features: 0-RTT resumption, encrypted SNI (ESNI/ECH), and post-handshake authentication → Validate that packet captures confirm TLS 1.3 handshake structure (single round-trip)
6. Use browser DevTools Security tab to verify TLS version for the connection → Confirm that TLS 1.3-specific features (0-RTT, encrypted extensions) function correctly
7. Test that browser prefers TLS 1.3 over older versions when both are available → 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: → Confirm that valid certificates from trusted CAs are accepted without warnings
   - 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 → Verify that expired certificates trigger security warnings and connection blocks
3. Verify that browser displays appropriate security warnings for invalid certificates → Check that self-signed certificates are rejected with clear error messages
4. Test that users cannot bypass critical certificate errors without explicit acknowledgment → Validate that hostname mismatches are detected and reported
5. Verify certificate chain validation using browser DevTools Security tab → Confirm that incomplete certificate chains are rejected
6. Test extended validation (EV) certificate display → Verify that certificates from untrusted CAs trigger warnings
7. Capture and analyze the certificate validation process → Check that users should explicitly acknowledge risk to bypass warnings
8. Test certificate validation with intermediate CA certificates → 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 → Test static pins for built-in domains (e.g., Google properties)
2. Navigate to the test server and verify that pins are stored by the browser → Confirm that browser correctly stores certificate pins from HTTP headers
3. Attempt to connect with a certificate that violates the pin (different public key) → Verify that connections with mismatched certificates are rejected
4. Verify that the browser rejects the connection due to pin validation failure → Check that pin validation errors display clear security warnings
5. Test pin expiration and max-age directive behavior → Validate that pins expire according to max-age directive
6. Test includeSubDomains directive for pin inheritance → Confirm that includeSubDomains directive applies pins to subdomains
7. Test report-uri directive for pin violation reporting → Verify that pin violations are reported to specified report-uri
8. Examine browser's HPKP/pin storage (chrome://net-internals/#hsts for Chromium) → Check that browser maintains persistent pin storage across sessions

**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` → Attempt to bypass HSTS with user override and verify it's prevented
2. Navigate to https://test.example.com and verify HSTS header is received → Browser receives and processes Strict-Transport-Security header
3. Attempt to navigate to http://test.example.com (non-HTTPS) and verify automatic upgrade to HTTPS → HTTP requests are automatically upgraded to HTTPS for HSTS domains
4. Test that browser stores HSTS policy persistently across sessions → HSTS policy persists across browser sessions
5. Verify includeSubDomains directive applies HSTS to all subdomains → includeSubDomains directive correctly applies to subdomains
6. Test HSTS policy expiration by setting short max-age values → HSTS policies expire according to max-age directive
7. Examine browser's HSTS storage (chrome://net-internals/#hsts) → Preloaded domains enforce HTTPS even on first visit
8. Test HSTS preload list for well-known domains → Users cannot bypass HSTS enforcement

**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: → Active mixed content (scripts, stylesheets, iframes) is completely blocked
   - 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 → Browser console displays clear mixed content blocking messages
3. Verify that active mixed content (scripts, stylesheets, iframes) is blocked → Passive mixed content may load with warnings (or be blocked in strict mode)
4. Test browser's handling of passive mixed content (images, audio, video) → Mixed content indicator appears in browser address bar/security indicator
5. Check browser console for mixed content warnings → CSP block-all-mixed-content directive blocks all mixed content
6. Test Content-Security-Policy: block-all-mixed-content directive → CSP upgrade-insecure-requests upgrades HTTP resources to HTTPS
7. Verify that upgrade-insecure-requests CSP directive upgrades HTTP to HTTPS → Form submissions to HTTP URLs are blocked or warned
8. Test mixed content indicator in browser address bar → 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: → Browser accepts certificates with valid SCTs
   - 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 → Certificates without SCTs are rejected with security errors
3. Verify that browser requires CT for publicly trusted certificates → DevTools Security tab displays CT compliance status
4. Check DevTools Security tab for CT information → Browser validates SCT signatures from known logs
5. Test that certificates without valid SCTs are rejected → CT is enforced for all publicly trusted certificates
6. Verify that browser validates SCT signatures → Multiple SCT delivery mechanisms are supported
7. Test CT enforcement for different certificate types (DV, OV, EV) → Browser maintains list of trusted CT log servers
8. Examine browser's CT policy compliance → 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) → Verify handling of expired or invalid OCSP responses
2. Navigate to the test server and capture the TLS handshake using packet capture tools → Browser successfully receives and validates stapled OCSP responses
3. Verify that browser receives and validates the stapled OCSP response → Packet captures show OCSP response in TLS handshake (CertificateStatus message)
4. Test server without OCSP stapling and verify browser falls back to OCSP responder query → Browser validates OCSP response signatures
5. Configure OCSP response indicating certificate is revoked and verify browser rejection → Revoked certificates are rejected based on OCSP response
6. Test OCSP response validation including signature verification → Browser falls back to direct OCSP query when stapling unavailable
7. Measure performance difference between stapled and non-stapled OCSP → OCSP Must-Staple extension is enforced (if present)
8. Test OCSP Must-Staple certificate extension enforcement → Performance metrics show faster connection with stapling

**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: → Test cipher suite restrictions for different TLS versions
   - 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 → Browser successfully negotiates strong cipher suites
3. Verify that browser refuses weak cipher suites → Weak cipher suites (RC4, DES, 3DES, NULL) are rejected
4. Capture cipher suite negotiation using packet analysis → Connection fails when only weak ciphers are available
5. Test browser's cipher suite preference order → Browser prefers AEAD ciphers over CBC-mode ciphers
6. Verify that AEAD (Authenticated Encryption with Associated Data) ciphers are preferred → Cipher suite negotiation follows secure ordering
7. Test that CBC-mode ciphers are avoided or deprioritized → Export-grade ciphers are completely disabled
8. Examine browser's supported cipher suite list → DevTools shows negotiated cipher suite

**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: → Test connection failure when only non-PFS ciphers are available
   - 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 → Browser successfully negotiates ECDHE/DHE cipher suites
3. Verify that browser prefers ECDHE/DHE over static RSA key exchange → Browser prefers PFS cipher suites over non-PFS alternatives
4. Capture TLS handshake to confirm ephemeral key exchange → Packet captures show ephemeral key exchange in handshake
5. Test that browser supports multiple elliptic curves (X25519, P-256, P-384) → Browser supports modern elliptic curves (X25519 preferred)
6. Verify proper DH parameter size enforcement (minimum 2048 bits) → DHE parameters meet minimum security requirements (2048+ bits)
7. Test TLS 1.3 behavior (all cipher suites provide PFS) → TLS 1.3 connections always provide PFS
8. Examine cipher suite preference order for PFS priority → DevTools Security tab indicates PFS status

**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: → Test browser's revocation checking cache behavior
   - 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 → Browser performs OCSP queries for certificates with OCSP URLs
3. Verify that browser checks certificate revocation status → Browser downloads and processes CRLs when available
4. Test OCSP responder queries (use network monitoring) → Revoked certificates are rejected with clear error messages
5. Test CRL download and parsing → Browser caches revocation check results appropriately
6. Configure OCSP responder to return "revoked" status and verify browser rejection → OCSP responses are validated (signature, freshness)
7. Test soft-fail vs hard-fail behavior when revocation check is unavailable → CRL validity period is checked
8. Measure performance impact of revocation checking → Browser handles revocation check failures gracefully

**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 → window.crypto.subtle is available in secure contexts only
2. Test key generation for various algorithms: → All mandatory algorithms are supported
   - 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 → Key generation produces keys of requested type and size
4. Test signing and verification operations → Encrypt/decrypt operations work correctly with proper padding
5. Test key derivation functions (PBKDF2, HKDF) → Sign/verify operations validate signatures correctly
6. Test key import/export in various formats (JWK, PKCS8, SPKI, raw) → Key derivation functions produce deterministic results
7. Verify that subtle crypto operations are only available in secure contexts (HTTPS) → Non-extractable keys cannot be exported
8. Test that cryptographic keys can be marked as non-extractable → Key usage constraints are enforced
9. Test key usage constraints (encrypt, decrypt, sign, verify, etc.) → Operations fail appropriately in insecure contexts (HTTP)
10. Verify proper error handling for invalid parameters → 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: → window.crypto.getRandomValues() is available and functional
   - Uint8Array, Uint16Array, Uint32Array
   - Different array sizes (1 byte to 65536 bytes)
2. Generate large samples of random data (millions of bytes) → Generated values pass statistical randomness tests
3. Test statistical properties of generated random data: → Repeated calls produce different, unpredictable values
   - Frequency test (chi-square)
   - Runs test
   - Entropy analysis
4. Verify that repeated calls produce different values → All typed array types are supported
5. Test that maximum size limit (65536 bytes) is enforced → Maximum size limit (65536 bytes) is enforced
6. Verify proper error handling for invalid parameters → QuotaExceededError thrown for oversized requests
7. Test that random values are available in both secure and insecure contexts → Random values have sufficient entropy (>= 7.9 bits per byte)
8. Compare randomness quality across multiple browser sessions → Performance is acceptable (can generate MBs per second)
9. Test performance of random number generation → 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: → Resources with matching integrity hashes load and execute successfully
   ```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 → Resources with mismatched hashes are blocked from loading
3. Modify resource content to mismatch integrity hash and verify blocking → Browser console displays clear SRI violation errors
4. Test multiple hash algorithms: sha256, sha384, sha512 → Multiple hash algorithms (sha256, sha384, sha512) are supported
5. Test multiple integrity values (fallback hashes) → Multiple integrity values allow fallback verification
6. Test CORS requirement for cross-origin SRI resources → Cross-origin resources require proper CORS headers for SRI
7. Verify browser console errors for SRI failures → SRI failures prevent resource execution/application
8. Test SRI with different resource types (scripts, stylesheets, preload links) → Network panel shows blocked resources with SRI violations
9. Test that SRI failures prevent script execution/style application → 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 → Examine browser settings for ECH/ESNI enablement
2. Publish ECH configuration in DNS (TLS HTTPS record type 65) → Browser successfully negotiates ECH/ESNI when available
3. Navigate browser to the test server → SNI extension is not visible in cleartext in packet captures
4. Capture TLS handshake using packet analysis tools → ClientHello contains encrypted_client_hello extension
5. Verify that SNI extension is encrypted in ClientHello message → Browser retrieves ECH configuration via DNS
6. Test fallback behavior when ECH is unavailable → Fallback to cleartext SNI works when ECH unavailable
7. Test that cleartext SNI is not visible in packet captures → DNS queries for ECH config are encrypted (DoH/DoT)
8. Verify browser DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) usage for ECH config retrieval → Browser DevTools or internal pages show ECH status
9. Test ECH with split-horizon DNS configurations → 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: → Certificate errors trigger full-page interstitial warnings
   - 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 → Warning messages clearly explain the security risk
3. Verify that warning messages clearly communicate security risk → Users should take explicit action to bypass (not easy clickthrough)
4. Test that warnings are difficult to bypass (require explicit user action) → Technical details are accessible via "Advanced" or similar link
5. Evaluate warning message clarity for non-technical users → Certificate details can be viewed and inspected
6. Test that technical details are available (certificate viewer) → Warning UI uses appropriate visual indicators (red, warning icons)
7. Verify that bypass actions are clearly labeled with risk warnings → Bypass options are clearly labeled with risk warnings
8. Test mobile and desktop warning UI differences → Error types are distinguishable in UI messages
9. Verify that errors are logged in browser console → 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 → Verify browser remembers HTTP-only sites to avoid repeated upgrade attempts
2. Navigate to HTTP URLs of sites that support HTTPS (http://example.com) → HTTP URLs are automatically upgraded to HTTPS
3. Verify that browser automatically upgrades to HTTPS → Address bar shows HTTPS protocol after upgrade
4. Test fallback behavior when HTTPS is unavailable: → Fallback to HTTP works with user consent when HTTPS 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 → User is warned before loading HTTP-only sites
6. Test HTTPS upgrade for embedded resources (images, scripts, iframes) → Browser remembers HTTP-only sites (cache/allowlist)
7. Test interaction with HSTS and upgrade-insecure-requests → Embedded resources are also upgraded
8. Measure performance impact of HTTPS upgrade attempts → HTTPS-first works alongside HSTS
9. Test HTTPS-first with different types of navigation (typed URL, bookmarks, links) → Network panel shows upgrade 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 → Static pins for built-in domains cannot be bypassed
2. Attempt various bypass techniques: → Custom root CA installation triggers user warnings
   - 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) → SSL interception is detected and indicated in UI
4. Verify that pin bypass attempts are detected and logged → Browser logs pin bypass attempts
5. Test enterprise policy controls for pinning exceptions → Certificate store modifications are visible to users
6. Verify user notifications for certificate store modifications → Enterprise policies can override pins with explicit configuration
7. Test that developer tools can't silently bypass pinning → Developer tools respect pinning (or show clear bypass warnings)
8. Examine browser internal state for pin enforcement → Security indicators reflect weakened security when pins bypassed
9. Test interaction between pin bypass and security indicators → 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 → Browser signals maximum supported TLS version correctly
2. Configure server supporting TLS 1.3 and TLS 1.2 → TLS_FALLBACK_SCSV is included in fallback connections
3. Attempt to force downgrade from TLS 1.3 to TLS 1.2 by manipulating ClientHello → Version rollback attacks are detected and connection aborted
4. Test TLS_FALLBACK_SCSV signaling value (RFC 7507) → Cipher suite downgrade attempts trigger handshake failure
5. Attempt downgrade attacks during connection: → Browser validates ServerHello.random for downgrade sentinels
   - Version rollback to older TLS versions
   - Cipher suite downgrade to weaker algorithms
   - Extension stripping attacks
6. Verify browser detects and rejects downgrade attempts → Extension stripping is detected through transcript hash validation
7. Test that Finished message MAC includes all handshake messages → Finished message properly authenticates handshake
8. Verify TLS 1.3 downgrade protection sentinel values in ServerHello.random → Console shows error messages for detected downgrade attempts
9. Test protection against truncation attacks → 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 1.1 connections are rejected or show warnings
   - 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 → SHA-1 certificates trigger security errors
3. Test deprecation timeline (when were features removed) → 1024-bit RSA keys are rejected
4. Verify that browser update notes document deprecated features → MD5 and RC4 are completely disabled
5. Test enterprise policy overrides for legacy support (temporary exceptions) → Legacy crypto rejections show clear error messages
6. Check browser developer documentation for deprecation roadmap → Browser documentation lists deprecated features with timelines
7. Test fallback behavior when modern crypto unavailable → Enterprise policies can temporarily enable legacy support (if necessary)
8. Verify that critical errors can't be bypassed for severely deprecated crypto → No silent fallback to insecure legacy protocols

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

**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 → Certificate store files have restrictive permissions (not world-readable)
2. Test that certificate store is protected with appropriate file system permissions → Certificate store cannot be modified without appropriate privileges
3. Attempt to modify certificate store while browser is running → Browser detects and handles certificate store corruption
4. Verify that certificate store changes are logged/auditable → Root CA additions/removals require explicit user consent
5. Test root CA certificate management: → Certificate store UI shows all installed root certificates
   - 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 → System certificate store integration works correctly
7. Verify that enterprise-managed certificates are clearly indicated → Enterprise-managed certificates are visibly marked
8. Test certificate store integrity verification mechanisms → Certificate store modifications are logged
9. Test that certificate store updates are secure and authenticated → Users are notified of certificate store changes
10. Verify user notifications for certificate store modifications → 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 → Test that advanced settings do not provide override mechanism
2. Establish baseline connection to verify pinning is active → Verify that enterprise policies cannot disable pinning for pinned domains
3. Modify server certificate to trigger pinning violation: → Test that developer tools cannot bypass pinning enforcement
   - 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 → Verify that command-line flags cannot disable pinning
5. Verify that browser blocks connection with clear error message → Test that error message explains pinning failure clearly
6. Verify that no "proceed anyway" or "add exception" option is available → Verify that pinning failures are logged for security monitoring

**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: → Verify that cryptographic operations occur within secure enclave
   - 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 → Test that key material is not accessible via memory dumps
3. Verify that browser detects and initializes hardware security features → Verify that browser preferences or about page indicates hardware security status
4. Perform cryptographic operations requiring key generation or usage: → Test that browser falls back gracefully if hardware security is unavailable
   - 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 → Verify that enterprise policies can require hardware-backed crypto
6. Test that private keys cannot be exported from hardware storage → 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 → Verify that enterprise policies can override user strictness settings
2. Identify available encryption strictness options: → Test that per-site exceptions can be configured for compatibility
   - 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: → Verify that strictness level changes are logged
   - 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 → Test that current strictness level is visible in security indicators
5. Test that configuration changes are persistent across browser sessions → Verify that documentation explains security implications of each level

**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: → Verify that security indicator changes are immediate upon navigation
   - 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: → Test that security indicators are accessible (screen reader compatible)
   - 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: → Verify that indicators follow consistent design across all platforms
   - 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.) → Test that users can easily distinguish secure from insecure connections
5. Test that indicators cannot be spoofed by web content → Verify that connection security details are easy to access

**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 → Test that dangerous configurations trigger prominent warnings
2. Verify that comprehensive encryption controls are available: → Verify that encryption settings can be exported/imported for consistency
   - 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: → Test that enterprise policies can restrict user control over specific settings
   - 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 → Verify that reset-to-defaults option exists for safe rollback
5. Test that changes require user acknowledgment of risks → Test that encryption setting changes are logged
6. Verify that current encryption configuration is clearly documented in UI → 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 → Verify that weak encryption configurations trigger visual warnings
2. Verify that encryption status is visible in multiple UI locations: → Test that encryption status persists in browser session info
   - Address bar security indicator
   - Settings page encryption section
   - About/information pages
   - Developer tools security panel
3. Test that status indicators show: → Verify that status indicators are accessible via keyboard navigation
   - 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 → Test that indicators work in all browsing modes (normal, private, reader)
5. Verify that indicators update dynamically to reflect current connection → Verify that encryption dashboard or summary page exists
6. Test that clicking indicators provides detailed encryption information → 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