Skip to content

The allowSSL server-trust override accepts the challenge without evaluating the trust #1512

Description

@jkmassel

Split out from #1497Swift executor URLSession error audit. Section D — Crash instead of classified error.

File references are to native/swift/Sources/wordpress-api/SafeRequestExecutor.swift unless noted; :NNN line numbers were verified against fix/converge-executor-error-classification.

Severity: high (security). The delegate's didReceive challenge handler (:347-363) returns (.useCredential, URLCredential(trust:)) as soon as the leaf certificate parses and its CN matches the allowlist — SecTrustEvaluateWithError is never called, so chain signature, issuer, and validity dates are never checked. A MITM can self-sign a certificate whose CN copies the legitimate certificate's CN (public information) and be accepted for every host previously passed to allowSSL(altNames:forCommonName:). The comment above the storage states the feature exists to tolerate a hostname missing from an otherwise-valid certificate; the fix is to re-evaluate the trust with hostname checking relaxed but chain validation intact (SecTrustSetPolicies with SecPolicyCreateSSL(true, nil), then SecTrustEvaluateWithError), falling through to .performDefaultHandling on failure. Compounds #1498: apps steered into allowSSL by a bogus name-mismatch reason find the exception "works" precisely because validation is fully bypassed.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions