mirror of
https://github.com/cesanta/mongoose.git
synced 2026-10-31 13:00:49 +00:00
44 lines
3.2 KiB
Markdown
44 lines
3.2 KiB
Markdown
# 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.
|