CVE-2025-21587: Timing Side-Channel Vulnerability in JSSE RSA Decryption

The Java Secure Socket Extension (JSSE) is the core framework in the Java runtime environment that provides secure Internet communications. It handles the Transport Layer Security (TLS) handshake protocol, negotiating cryptographic keys and verifying server authenticity. This specific vulnerability, CVE-2025-21587, resides within the JSSE implementation of the RSA decryption mechanism during the TLS Client Key Exchange.

An unauthenticated remote attacker can exploit a timing side-channel in this component, exposing systems to Marvin and Bleichenbacher-style decryption oracle attacks. The vulnerability is classified under CWE-385 (Covert Timing Channel) and CWE-203 (Observable Discrepancy). It allows attackers to iteratively deduce the contents of encrypted TLS messages without possessing the server's private RSA key.

The vulnerability affects deployments utilizing RSA-based key exchange mechanisms where the server decrypts a Pre-Master Secret (PMS) provided by the client. Modern configurations utilizing Ephemeral Diffie-Hellman (ECDHE/DHE) or TLS 1.3 are not susceptible because they do not utilize RSA decryption during the key exchange phase. However, legacy enterprise systems often retain support for RSA key exchange to maintain backward compatibility with older clients.

During a standard TLS-RSA handshake, the client encrypts a 48-byte Pre-Master Secret (PMS) using PKCS#1 v1.5 padding. The padded payload must begin with specific bytes (0x00 and 0x02), followed by non-zero padding bytes, and a zero byte separator before the PMS. If the server detects malformed padding or incorrect TLS version encoding within the decrypted PMS, it must handle the error in a manner that is indistinguishable from successful decryption.

The vulnerable JSSE implementation failed to perform padding and version validation in constant time. The decryption pipeline executed conditional checks that aborted early or generated different execution branch pathways depending on whether the padding structure was correct. Specifically, the helper class RSAPadding and version checks in KeyUtil.checkTlsPreMasterSecretKey introduced microarchitectural differences that leaked processing time through CPU branch prediction and JIT compiler optimizations.

These microsecond-level variations allow an attacker to determine if a chosen ciphertext, when decrypted, conforms to the PKCS#1 v1.5 padding rules. By sending a structured series of blinded ciphertexts and measuring the time elapsed before the server returns a TLS alert, the attacker constructs an oracle. Over many iterations, this timing discrepancy leaks the cryptographic structure of the target ciphertext, leading to complete plaintext recovery.

The vulnerability stemmed from non-constant-time checks in RSAPadding.unpadV15(). The legacy code iterated over the decrypted byte array using conditional branches to locate the padding boundary. When an invalid padding byte or incorrect padding length was encountered, the runtime executed branch instructions that affected execution duration, leaking the failure state to the network.

The patch introduces a dedicated method, unpadForTls, within RSAPadding.java. This method implements a strictly branchless, bitwise selection mechanism. It processes the entirety of the decrypted block without executing any conditional jumps, ensuring that the execution path remains identical regardless of whether the padding or version verification fails.

Below is an illustrative comparison demonstrating the transition from the legacy conditional implementation to the branchless, constant-time design implemented in the patch:

// Legacy Non-Constant Time Implementation
int p = 0;
while (k < padded.length) {
    int b = padded[k++] & 0xff;
    if ((b == 0) && (p == 0)) {
        p = k; // Conditional execution depending on input data
    }
    if ((k == padded.length) && (p == 0)) {
        bp = true;
    }
}
 
// Patched Constant-Time Implementation
public byte[] unpadForTls(byte[] padded, int clientVersion, int serverVersion) {
    int paddedLength = padded.length;
    // Bitwise flag initialized based on padding block type
    int bp = (((int) padded[0] | ((int)padded[1] - PAD_BLOCKTYPE_2)) & 0xFFF);
 
    int k = 2;
    while (k < paddedLength - 49) {
        int b = padded[k++] & 0xFF;
        bp = bp | (1 - (-b >>> 31)); // Branchless evaluation of zero-byte separator
    }
    bp |= ((int)padded[k++] & 0xFF);
    int encodedVersion = ((padded[k] & 0xFF) << 8) | (padded[k + 1] & 0xFF);
 
    // Constant-time version verification using bitwise manipulation
    int bv1 = clientVersion - encodedVersion;
    bv1 |= -bv1;
    int bv3 = serverVersion - encodedVersion;
    bv3 |= -bv3;
    int bv2 = (0x301 - clientVersion);
    bp |= ((bv1 & (bv2 | bv3)) >>> 28);
 
    // Bitwise selection mask generation
    bp = (-bp >> 24);
    byte[] data = Arrays.copyOfRange(padded, paddedLength - 48, paddedLength);
    byte[] fake = new byte[48];
    random.nextBytes(fake); // Always generated to ensure identical entropy usage
 
    // Select either valid data or fake secret in constant time
    for (int i = 0; i < 48; i++) {
        data[i] = (byte)((~bp & data[i]) | (bp & fake[i]));
    }
    return data;
}

This constant-time implementation ensures that SecureRandom is always invoked to generate a fake secret, maintaining identical computational overhead. The bitwise selection (~bp & data[i]) | (bp & fake[i]) eliminates data-dependent execution variations, successfully closing the timing side-channel.

Exploiting CVE-2025-21587 requires a multi-step mathematical process to narrow down the possible values of the targeted Pre-Master Secret. The attacker must first intercept a legitimate TLS handshake and capture the encrypted Client Key Exchange message. This captured ciphertext represents the starting point for the mathematical blinding process.

The attacker generates a series of modified ciphertexts by multiplying the intercepted ciphertext with a chosen random blinding factor. These modified ciphertexts are transmitted to the target server in separate, independent TLS connection attempts. The attacker measures the time delay between sending the Client Key Exchange message and receiving the inevitable TLS Handshake Failure alert.

Because the timing difference is extremely small (often in the microsecond or nanosecond range), the attacker must use statistical filtering to eliminate network jitter. High-resolution packet capture or close network proximity to the target server is critical for success. Over millions of probes, the attacker maps the boundaries of the RSA decryption output to eventually reconstruct the exact session keys.

The successful exploitation of CVE-2025-21587 completely compromises the confidentiality of affected TLS sessions. By extracting the Pre-Master Secret, an attacker can decrypt historical and future network traffic that was encrypted using RSA key exchange suites. This exposes sensitive administrative credentials, API tokens, and proprietary payload data transmitted over HTTPS, LDAPS, or IMAPS.

In addition to passive decryption, a highly capable attacker can use the timing oracle to perform unauthorized digital signature generation. This allows the attacker to forge authentication parameters or establish impersonated secure sessions, leading to unauthorized access to enterprise resources. The vulnerability does not affect the availability of the system, as the probe requests do not crash the Java Virtual Machine.

The CVSS v3.1 base score is 7.4, reflecting a high-severity rating with high complexity. While the technical prerequisites are high, the potential impact on data confidentiality and integrity remains severe. Systems configured with TLS 1.3 or disabling static RSA key exchanges are naturally shielded from this attack vector.

The primary remediation path is the installation of the April 2025 Critical Patch Update or corresponding OpenJDK updates. Upgrading the Java Runtime Environment introduces the constant-time unpadForTls parsing logic, eliminating the timing side-channel. System administrators should verify that all instances of Oracle Java SE or GraalVM are updated to the fixed version branches.

If patching cannot be performed immediately, the vulnerability can be fully mitigated by disabling RSA-based key exchange suites in the application server configuration. Forcing the use of Ephemeral Diffie-Hellman (ECDHE/DHE) cipher suites ensures that RSA decryption is never invoked for key establishment. This blocks the attack vector entirely, even on unpatched Java versions.

Additionally, organizations should configure network devices to enforce TLS 1.3 where possible and monitor for anomalies. Security teams can configure Intrusion Detection Systems to detect anomalous volumes of TLS handshake failures originating from a single IP address. Although this does not prevent the underlying side-channel, it alerts security operations to active oracle probing behavior.