SSL/TLS: 8 Checks

This rule inspects the parameters a discovered HTTPS or TLS network service negotiated with the scanner — the single version and suite this one handshake chose, not everything the service would accept. This rule fails when the service's TLS version is an obsolete protocol (SSL_2_0, SSL_3_0, TLS_1_0, TLS_1_1, or their DTLS 1.0 equivalents) or its cipherSuite is an insecure RC4 suite. For what the service accepts but did not negotiate here, see the insecure-acceptance rule over supportedVersions.

Rationale: SSL 2.0/3.0 and TLS 1.0/1.1 contain protocol-level weaknesses (POODLE, BEAST, downgrade attacks) and RC4 is cryptographically broken. Services negotiating them provide little effective transport security.

Impact: An attacker positioned on the network path can downgrade, decrypt, or tamper with the service's traffic, exposing credentials and sensitive data.

This rule inspects the parameters a discovered HTTPS or TLS network service negotiated with the scanner — the single version and suite this one handshake chose, not everything the service would accept. This rule fails when the service's TLS version is TLS_1_2 (or DTLS_1_2) or its cipherSuite is a weak suite (static-RSA key exchange, or 3DES/CBC block ciphers). For what the service accepts but did not negotiate here, see the weak-acceptance rule over supportedCipherSuites. Services already using an insecure protocol or cipher are excluded here because they are reported at higher severity by the insecure-SSL/TLS rule.

Rationale: TLS 1.2 and CBC/3DES/static-RSA cipher suites are no longer state of the art: they lack forward secrecy or modern AEAD constructions and are subject to a range of downgrade and padding-oracle weaknesses. TLS 1.3 with AEAD suites is the recommended baseline.

Impact: Weak transport parameters increase the attack surface for interception or tampering and may fail modern compliance requirements.

This rule inspects the protocol versions and cipher suites a discovered HTTPS or TLS service accepts, discovered by probing each version rather than recording the one a scan happened to negotiate. This rule fails when supportedVersions contains an obsolete protocol (SSL_2_0, SSL_3_0, TLS_1_0, TLS_1_1, or their DTLS 1.0 equivalents) or supportedCipherSuites contains an insecure RC4 suite.

Rationale: A service that negotiates TLS 1.3 with a modern client can still accept SSL 3.0 from an attacker who asks for it. Only the accepted set reveals that; the negotiated version does not.

Impact: An obsolete protocol remains reachable by any client that requests it, exposing the service to POODLE, BEAST, and downgrade attacks regardless of what better clients negotiate.

Note: Any enumeration is a lower bound on what the service accepts; enumerationTruncated additionally means the probe budget ran out before it finished. A FAIL stays valid either way — truncation removes coverage, it does not invalidate a parameter that was observed to be accepted.

This rule inspects the cipher suites a discovered HTTPS or TLS service accepts, discovered by offering the suites not yet selected until the service declines them all. This rule fails when supportedCipherSuites contains a weak suite (static-RSA key exchange, or 3DES/CBC block ciphers). Services that accept an insecure protocol or an insecure RC4 suite are excluded here because the insecure-acceptance rule reports both at higher severity.

Rationale: A service that negotiates AES-GCM with a modern client can still accept 3DES from one that asks for it. The negotiated suite hides this; the accepted set does not.

Impact: A weak suite remains reachable by any client that requests it, exposing the traffic to Sweet32 and CBC padding-oracle attacks regardless of what better clients negotiate.

Note: Any enumeration is a lower bound on what the service accepts; enumerationTruncated additionally means the probe budget ran out before it finished. A FAIL stays valid either way.

This rule inspects whether a discovered HTTPS or TLS service imposes its own cipher-suite order, established by offering the same two suites in both orders and comparing what the service selects. This rule fails when serverPreferenceEnforced is false.

Rationale: When the service honors the client's order, the client decides which of the mutually supported suites is used. An attacker who controls or influences the client can then steer the connection onto the weakest suite the service still accepts.

Impact: Downgrade resistance depends entirely on the client. Removing weak suites remains the primary fix; server-enforced order is the defense in depth that limits the damage while any remain.

Note: A service whose order could not be determined reports null and passes — absence of evidence is not a finding.

This rule inspects the TLS certificate verification result of a discovered HTTPS or TLS service. This rule fails when certificate verification failed (certVerifyOk == false) — e.g. an expired, self-signed, untrusted, or hostname-mismatched certificate.

Rationale: A certificate that fails validation provides no assurance of the server's identity and undermines the trust model of TLS.

Impact: Clients cannot distinguish the legitimate server from an impostor, enabling adversary-in-the-middle attacks.

This rule inspects the certificate validity of a discovered HTTPS or TLS service. This rule fails when a service presents a currently valid certificate whose notAfter is within the next 30 days. Certificates that have already expired or otherwise fail validation are reported by the invalid-certificate rule, not here.

Rationale: Renewing certificates proactively before they lapse prevents outages and emergency changes.

Impact: A lapsed certificate causes client connection failures and may push users to bypass certificate warnings.

This rule inspects the revocation state of the certificate a discovered HTTPS or TLS service presents, established from an OCSP response the service stapled to its handshake or from a certificate revocation list fetched and verified against the issuing authority. This rule fails when revocationStatus is REVOKED.

Rationale: Revocation is the issuer withdrawing its assurance about a certificate, most often because the private key is known to be in someone else's hands. Expiry is a schedule; revocation is a decision, and it is the stronger signal of the two.

Impact: A revoked certificate offers no assurance of the service's identity. When the reason is KEY_COMPROMISE an attacker may hold the private key, so traffic to this service can be intercepted or impersonated by anyone who does.

Note: A status of UNKNOWN passes. It means no revocation source could be consulted — a private certificate authority, an unreachable endpoint, or a short-lived certificate that publishes none — and absence of evidence is not evidence of revocation.