mongoose/resources/specs/areas/tls.md

Security Scan Area: tls

Target

Area: tls

This area covers the complete Mongoose TLS implementation represented by the primary files.

Primary files:

• src/tls_aes128.c
• src/tls_builtin.c
• src/tls_chacha20.c
• src/tls_dummy.c
• src/tls_mbed.c
• src/tls_openssl.c
• src/tls_rsa.c
• src/tls_uecc.c
• src/tls_x25519.c

Perform a focused security review centered on these files and this security surface.

Supporting code elsewhere under src/ may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside src/ or independently review unrelated areas.

Connection, core, network, and helper code under src/ may be inspected when needed to understand the complete TLS execution path.

Area-Specific Security Guidance

Mandatory High-Risk Coverage: Built-In TLS

The built-in TLS implementation (MG_TLS_BUILTIN) is a mandatory high-risk review target. Perform a substantial security analysis of all security-relevant built-in TLS code, including parsing, cryptographic processing, authentication and certificate validation, length and buffer handling, protocol state, cross-call behavior, and failure paths.

Trace attacker-controlled TLS peer input through normal client and server execution, including traffic received before peer authentication is complete. Report any credible memory-safety, authentication, confidentiality, integrity, state-corruption, or remotely triggerable availability vulnerability.

TLS, Certificate, Hostname Verification, and Cryptographic Validation:

• Review all TLS backends, including built-in TLS, mbedTLS, OpenSSL, WolfSSL, and custom TLS integration, for equivalent security behavior where possible.
• Flag certificate verification bypasses, accidental skip_verification use in security-sensitive defaults, missing hostname verification when name/SNI is available, or inconsistent validation across TLS backends.
• For hostname verification, check wildcard handling carefully. A wildcard certificate identity must not match multiple DNS labels. For example, *.example.com must not match a.b.example.com.
• Verify that wildcard matching is applied only to certificate presented identifiers, not to arbitrary reference identifiers or general DNS glob matching.
• Review mg_match or other glob/matching helpers if used for certificate identity checks, authorization checks, filesystem paths, routing, or topic matching. Flag cases where glob semantics are broader than the security policy requires.
• Check certificate parsing for DER/PEM boundary errors, length overflows, malformed ASN.1, extension parsing mistakes, name constraints, SAN vs CN precedence, embedded NUL, and invalid string type handling.
• Review TLS record parsing, handshake transcript handling, key schedule, random generation, ECC/X25519 operations, AES-GCM nonce/tag handling, and error handling for memory safety and authentication failures.
• Flag any behavior that silently falls back from verified TLS to unverified TLS or plaintext.
• Check that TLS receive/send error paths cannot corrupt connection state, reuse freed buffers, or continue processing unauthenticated plaintext as encrypted data.