Compromised TLS Certificates

Eight TLS certificates associated with the Indian certificate authority eMudhra Limited were compromised because their private keys were extraordinarily weak. Instead of having strong, unpredictable keys, the affected certificates used values ranging from roughly 3 to 8 bits of size. The article lists the values as 4, 56, 66, 115, 155, 156, 230, and 237.

A private key protects a certificate’s identity. If an attacker can discover that key, the attacker may be able to impersonate the related website or VPN endpoint. During an active adversary-in-the-middle attack, the attacker can receive encrypted traffic, decrypt it, reencrypt it, and forward it.

The immediate danger appears greatest for VPN users and people on networks controlled by an attacker. Certificate-transparency logs may help expose unauthorized certificates after issuance, but they do not prevent the original failure. Cleanup is expected to be difficult.

A TLS certificate is a digital credential that identifies a website, server, or VPN endpoint. It contains the service’s public key and identifying information, and a certificate authority signs it. During a TLS connection, the other party checks that signature and the certificate’s name before trusting the endpoint.

The certificate works with a matching private key. The private key stays secret, while the public key can be shared. Together, they help prove that the endpoint controls the identity named in the certificate and support establishment of an encrypted connection. The certificate does not, by itself, make every connection safe.

In this incident, eMudhra-issued certificates had dangerously weak private keys. An attacker who recovered one could impersonate its service during an active interception. The article emphasizes VPNs and networks controlled by attackers, where traffic can be redirected through the attacker.

A normal NIST P-384 elliptic-curve private key contains roughly 384 bits of entropy. That represents about 2^384 possible choices, which the article describes as a number with 116 digits. Searching that space is intended to be infeasible.

The compromised keys were reported as ranging from 3 to 8 bits, with the listed values 4, 56, 66, 115, 155, 156, 230, and 237. Even the largest reported weakness is vastly below the expected 384-bit scale. A key with only a handful of unpredictable bits has very few possibilities compared with a properly generated key.

This difference makes the certificates vulnerable to discovery and misuse. The article quotes engineers calling the defect something that “should not be possible.” It suggests a broken key-generation interface or example code may have reached production, although the exact cause was unknown.

A compromised private key can let an attacker present the corresponding TLS certificate as though the attacker were the legitimate website or VPN endpoint. The connection may then appear properly identified to the other party, even though the attacker is handling the traffic.

The article describes the mechanism as an active adversary-in-the-middle attack. The attacker acts as a proxy between two TLS parties, receives encrypted traffic, decrypts it, reencrypts it, and sends it onward. This creates an opportunity to read or alter communications while maintaining the connection between the two sides.

The certificate alone does not automatically expose everyone’s traffic. The attacker must also be able to intercept and control the network path. Such capabilities can belong to highly resourced attackers, but they are easier for someone controlling a local network, such as a coffee shop, university, or other organization.

The article identifies VPN users as the most immediate concern, particularly in countries where governments are likely to maliciously intercept traffic. A VPN is meant to protect communications across networks, so a compromised certificate can undermine confidence that users are connected to the genuine endpoint.

The key issue is network position. An attacker must operate between the two TLS parties and pass traffic through a proxy. Someone controlling a local network at a coffee shop, university, or other organization has a much easier path to that position than a distant attacker with no network control.

The article also notes that some interception capabilities are usually limited to the most well-resourced attackers. End users have little recourse beyond delaying many non-browser TLS connections until providers confirm that updates are installed. The warning extends beyond VPNs because other TLS-protected services may also depend on affected certificates.

Certificate-transparency logs create public records of issued certificates. Organizations can monitor those records and look for certificates that were created without authorization. In this incident, the article says transparency logs account for much of the certificate system’s failure by making suspicious issuance visible.

Their protection is mainly detective, not preventive. A log does not stop a certificate authority from issuing a defective or unauthorized certificate. It also does not automatically remove the certificate or block an attacker. A party must actively monitor massive feeds, identify the problem, and respond.

The timing matters. Logs work only after an unauthorized certificate has been issued, so an attacker may have an opportunity before detection and cleanup. The article calls the cleanup another mess. Users must wait for assurances that updates are in place, while the broader certificate regime remains dependent on every link working correctly.

Entropy is the amount of unpredictability in a private key. More entropy means more possible keys an attacker must consider. A normal NIST P-384 key has roughly 384 bits of entropy, or about 2^384 possible choices. That enormous space is what makes guessing the private key impractical.

A key with only a few bits of entropy has a tiny search space by comparison. An attacker can test possible values far more easily, recover the private key, and potentially use it to impersonate the certificate holder. The article reports affected key sizes of roughly 3 to 8 bits, rather than the expected 384-bit strength.

This is why secure encryption depends on key generation as well as encryption algorithms. Even a strong TLS system becomes vulnerable when its private keys are predictable. The incident suggests that a defective interface or leaked example code may have produced the weak keys, though the exact cause was not known.