What TLS vulnerabilities are and how to find them on your domain

TLS vulnerabilities like Heartbleed and ROBOT were patched years ago, yet they still turn up on live servers behind valid certificates. SecRift actively probes for four of them and tells you exactly which ones affect your domain.

A valid TLS certificate proves your server's identity. It says nothing about whether the software behind it has a flaw that lets an attacker read encrypted traffic, steal a private key, or knock the server over. Four such flaws keep showing up in real scans years after their fixes shipped: Heartbleed, ROBOT, OpenSSL CCS Injection, and insecure renegotiation. This guide explains what each one does, why an active probe is the only reliable way to catch it, and how SecRift reports the results.

What TLS vulnerabilities are

A TLS vulnerability is a bug in how a server's TLS software handles the protocol - not a setting you turned on, but a defect in the implementation itself. That makes it different from the other two things people check on an HTTPS endpoint. Configuration is about which protocol versions and cipher suites you offer. The certificate is about identity and trust. A vulnerability sits underneath both: your server can run TLS 1.3, present a perfect certificate, and still be exploitable because the library build it depends on carries an old flaw.

The four vulnerabilities here are all fixed. The catch is that "fixed" and "deployed" are not the same thing. A server that was never rebuilt, an appliance nobody updates, or a snapshot restored from years ago can quietly reintroduce a flaw the rest of the internet moved past a decade ago.

The four vulnerabilities SecRift tests

Heartbleed (CVE-2014-0160). A bug in OpenSSL's TLS heartbeat handling let any client ask the server to hand back up to 64 KB of its own memory - unauthenticated, and invisible to application logs. Repeated requests can rebuild private keys, session tokens, and passwords out of that memory. It was fixed in OpenSSL 1.0.1g in April 2014, but old base images and restored servers still bring it back.

ROBOT (Return of Bleichenbacher's Oracle Threat). If a server leaks whether an RSA-encrypted value had valid padding - through timing or distinct error responses - an attacker can use that as an oracle to decrypt sessions or forge signatures without ever holding the private key. Only servers that still offer RSA key exchange are exposed. A modern server using ECDHE cipher suites isn't affected at all, and the fix is to drop RSA key exchange in favor of forward-secret suites.

OpenSSL CCS Injection (CVE-2014-0224). The handshake only switches to encryption after both sides agree on keys, signaled by a ChangeCipherSpec message. Vulnerable OpenSSL versions accepted that message too early, letting a man-in-the-middle force weak keying material and take over the session. It needs both ends running a vulnerable OpenSSL, which limits real-world exposure, and was patched in June 2014.

Insecure renegotiation. TLS lets a live connection renegotiate its parameters, and two problems follow from that. Without the RFC 5746 renegotiation_info extension (CVE-2009-3555), an attacker can splice injected data in front of a victim's request and the server treats it as one stream. Separately, honoring client-initiated renegotiation (CVE-2011-1473) gives an attacker a cheap way to burn server CPU. SecRift reports the combination of both.

Why they still matter

Each of these lets an attacker break the confidentiality or integrity of a connection outright, not just weaken it - so a single positive is a real finding, not a style note. And because they live in the implementation, you can't rule them out by reading a version banner or a cipher list. A server can look completely modern and still be running a patched-looking build that never actually got the patch.

That's why an active probe matters. Instead of guessing from a version string, SecRift connects to your server and exercises the exact behavior each attack relies on. The answer is a direct yes or no about your server, as it runs today.

Common causes

• Old base images and long-lived containers. An image built years ago pins an OpenSSL version that carries one of these flaws, and every container from it inherits the problem.
• Restored snapshots and forgotten machines. A VM brought back from an old backup, or one nobody has logged into in years, can run a TLS stack the rest of your fleet retired long ago.
• Legacy appliances and load balancers. Network gear terminating TLS often lags far behind server software on updates.
• RSA key exchange left enabled. Keeping legacy RSA cipher suites around for old clients is what keeps ROBOT in play.
• A pre-2010 TLS stack. Anything older than the RFC 5746 fix lacks secure renegotiation by definition.

How SecRift checks TLS vulnerabilities

SecRift runs four dedicated probes against your domain's HTTPS endpoint on port 443. Every probe is an active test against your live server, not an inference from its version or cipher list, and each produces one scored finding:

• Heartbleed - sends a malformed heartbeat request and checks whether the server leaks memory back. It carries the most weight because it can expose private keys with no trace at all.
• ROBOT - tests whether the server behaves as an RSA padding oracle. A server that doesn't offer RSA key exchange is reported as not applicable rather than passed with caveats.
• CCS Injection - sends an early ChangeCipherSpec message and confirms the server rejects it. It's weighted slightly lower because exploitation needs both endpoints to be vulnerable.
• Renegotiation - checks both RFC 5746 secure renegotiation support and whether the server accepts client-initiated renegotiation, then reports the combination. Missing RFC 5746 is a serious finding on its own.

Passing all four means your server rejected every active probe - stronger evidence of a clean endpoint than any version check can give you. These probes sit alongside SecRift's certificate and configuration coverage, and pair naturally with the transport-side checks behind SMTP TLS on your mail servers.

Run a free scan on any domain at secrift.com and see your TLS vulnerability posture in seconds.