64 KB at a time

01 / THE CASE

A false length, a real leak

TLS encrypts communications between peers; OpenSSL is one software implementation used by applications to provide that protection. Its heartbeat extension lets either peer ask for a small payload to be echoed, keeping a connection alive or checking that it still works.

A heartbeat request carries a length and a payload. The receiving implementation must check that the length fits the bytes actually present. Vulnerable OpenSSL trusted a larger claimed length and copied bytes beyond the payload into its reply. Those bytes came from the application's process memory.

02 / DISCOVERY

Independent paths to the same bug

Google Security researcher Neel Mehta found and privately reported the flaw. Riku, Antti and Matti at Codenomicon independently found it and reported it through Finland's NCSC-FI, according to the original Heartbleed project page. OpenSSL credits Mehta in its advisory; the Heartbleed site credits both discoveries. These accounts can coexist.

On 7 April 2014 OpenSSL issued its advisory and released version 1.0.1g. Codenomicon's name, heart logo and public explanation helped a low-level memory error reach an audience far beyond security teams.

03 / MECHANISM

What was actually sent?

1. Connect. A peer establishes a TLS connection to a service using a vulnerable OpenSSL build with heartbeat support.
2. Claim. The peer sends a heartbeat message whose declared payload length is greater than the payload actually supplied.
3. Echo. The affected handler allocates a reply according to the declared size and copies too many bytes from the request buffer.
4. Receive. The peer sees the real payload followed by adjacent bytes from the process memory. A new request can produce different contents.

The vulnerable library might be used on either side of the connection. A server was the familiar public-facing risk, but the OpenSSL advisory explicitly includes a connected client or server. The TLS transport still encrypted the reply in transit; the connected peer could read the memory after decryption because it was the intended recipient of that reply.

Why the 64 KB headline matters

The maximum per request sounds small, but process memory can hold credentials, active session material and possibly private key fragments. A single scan result does not establish what leaked or whether anyone previously collected it. The risk comes from what could be present and from repeated requests while a vulnerable process was running.

04 / SCOPE

Who was affected?

Upstream OpenSSL 1.0.1 through 1.0.1f and some 1.0.2 beta builds were affected; 1.0.1g fixed the flaw. Releases before 1.0.1 were not affected by this issue. A distribution may backport the fix while preserving an older-looking version number, so check the vendor advisory and the library loaded by the running service.

Exposure also required a service or client built against a vulnerable OpenSSL library and using the affected heartbeat path. Finding the library installed on disk is a starting point, not a verdict on a particular TLS endpoint.

05 / LAB · CONTROLLED VERIFICATION

See the difference locally

Goal: compare a TLS service backed by an affected OpenSSL build with the same service after applying its fix. Use two disposable, isolated virtual machines or containers with a private network, under your control. Bind the test service to localhost and use synthetic data only. Obtain old and corrected packages from a distribution's historical package archive and pin their checksums; package acquisition and exact service start commands depend on the chosen distribution, so this article does not pretend a universal one-line setup exists.

1. Identify the library and endpoint

On each target, record the OpenSSL version and the vendor package revision. Then establish a TLS connection to your local test service on port 8443. A successful handshake confirms reachability; neither command proves the heartbeat flaw.

openssl version -a

openssl s_client -connect 127.0.0.1:8443 -servername localhost </dev/null

2. Compare the same check before and after the fix

From the same controlled environment, run Nmap's ssl-heartbleed script against 127.0.0.1:8443. On the vulnerable build, its output can report VULNERABLE; on the corrected build, it should not report vulnerability. Check the script's actual output, the service configuration and package advisory together; silence or a failed handshake alone is inconclusive.

nmap -sV -p 8443 --script ssl-heartbleed 127.0.0.1

3. Record the observations

Keep the Nmap output, the package revision, the service startup command and the endpoint for both runs. The meaningful comparison is the same target service and port before and after the library fix. Do not include memory excerpts, keys or live user data in a published screenshot. This journal has reviewed the procedure and the Nmap script documentation but has not executed this lab; results above are expected observations, not measured results.

06 / RESPONSE

Fix the process, then the trust

Apply the vendor's corrected OpenSSL package or equivalent security update and restart every service using the old library. Confirm which library the running process loaded. Depending on the system and exposure, generate new private keys, replace affected certificates and revoke the old ones where supported; rotate credentials and session material that may have been exposed. Scanning after the update checks for a remaining vulnerable endpoint but cannot tell you what was disclosed earlier.

07 / TAKEAWAY

The boundary is the story

Heartbleed turned a length field that should have been checked into an instruction to copy memory. It showed how one mistake in widely used infrastructure can put private information at risk across unrelated services. The lasting lesson is to validate untrusted lengths against the actual message buffer, and to verify that fixes reach the processes still running in production.