TLS and certificate analysis

TLS is what turns HTTP into HTTPS. A site can have a valid padlock and still accept obsolete protocol versions, weak cipher suites or a certificate that is about to expire. This check records how the server negotiates TLS and whether the certificate it presents is one a browser should trust.

What the check does

ScanBastion opens a series of TLS connections to the target on port 443 and, where the site answers, on any other HTTPS port discovered in links during the crawl. Each connection offers a different set of protocol versions and cipher suites to learn what the server will accept. It also fetches the certificate chain and makes a plain-HTTP request to see whether the site redirects to HTTPS. No data is sent inside the connections beyond a normal request for the home page.

Because every connection is a legitimate TLS handshake, this check is safe to run against production. It is bounded to a fixed number of handshakes per target and respects the scan's overall rate limit.

What is assessed

Protocol versions

TLS 1.0 and 1.1 were formally deprecated in RFC 8996 and are rejected by current browsers. A server still accepting them is reported as Medium, because an attacker who can interfere with the connection may be able to force a downgrade for older clients. SSL 2.0 or 3.0 being accepted is reported as High. TLS 1.3 support is noted as informational.

Cipher suites

Suites using RC4, 3DES, export-grade keys, NULL encryption or anonymous key exchange are reported, with severity depending on the weakness. The absence of forward secrecy (no ECDHE or DHE suites offered) is noted, because without it a future key compromise exposes past traffic. The check reports the server's preferred suite for each protocol version.

Certificate

• Validity window. Expired certificates are High. Certificates expiring within 14 days are Medium, within 30 days Low, so a report can be acted on before the site breaks.
• Hostname match. The certificate must cover the hostname being scanned, including the www and bare-domain variants if both serve content.
• Chain. A missing intermediate certificate is a common finding: it works in browsers that have cached the intermediate and fails everywhere else.
• Key and signature. RSA keys under 2048 bits and SHA-1 signatures are reported.
• Issuer and type. Self-signed or unknown-issuer certificates are reported as High, since every visitor sees a warning.

HTTPS enforcement

The check requests http:// and records whether the response is a redirect to https://, and whether Strict-Transport-Security is then set. A site that serves content over plain HTTP without redirecting is reported as Medium. Pages that load scripts or styles over HTTP from an HTTPS page (mixed content) are reported by the passive ZAP rules, which see the page bodies.

An example finding

What this check cannot tell you

• Other hostnames on the same server. TLS settings can differ per virtual host. Only the verified hostname and its www variant are tested.
• The origin behind a CDN. When a CDN terminates TLS, the check sees the CDN's configuration. The connection from the CDN to the origin is invisible from outside.
• Client-certificate or mutual-TLS setups. These are not probed.
• Non-HTTPS services. Mail, database and other ports are out of scope; this is a website scanner, not a port scanner.

Fixing TLS findings

Nearly all TLS findings are configuration, not code. The Mozilla SSL Configuration Generator produces a current, tested configuration for every common server; the "Intermediate" profile is the right default for a public website. Certificate findings are usually solved by automating renewal, for example with Let's Encrypt, and by installing the full chain the issuer provides rather than the leaf certificate alone.