This Number Broke the Internet Last Week (twice...)

Summary

The video examines two unrelated cybersecurity incidents that both produced the number four—a coincidence the host compares to an XKCD joke about random-number generation.

Weak intermediate certificate keys at I-mudhra

HTTPS certificates rely on a chain of trust: a root certificate authority (CA) issues intermediate certificates, which can then issue certificates for websites. If an intermediate CA’s private key is exposed or guessable, an attacker could potentially create convincing certificates for other sites and intercept traffic from devices that still trust that CA.

According to the video, eight I-mudhra intermediate certificates had extremely weak private keys. The reported values were 4, 56, 66, 115, 155, 156, 230, and 237. The host says the suspected cause was a problem in the certificate-generation script that left the keys with only one byte of entropy, despite the intended much larger key space. The exact cause was not yet fully known.

The video discusses certificate revocation lists (CRLs), which tell software not to trust compromised certificates. Updated systems may receive revocation information, but embedded devices that do not regularly update could continue trusting compromised certificates. The host also notes that I-mudhra left the TLS business after the issue received social-media attention, and says TLS accounted for about 1% of its revenue.

The site imadra.we-have-a-problem.com, mentioned in the video, can be used to test whether a system accepts a certificate chain tied to the affected CA. The host also cites a report that, as of October 28, some Apple-shipped developer tools—including Git, curl, and Python 3—still trusted the compromised certificates.

A separate Diffie–Hellman bug in GoAhead-based devices

The second incident involved a different flaw in the GoAhead web server’s TLS implementation, reportedly affecting many IoT, firewall, operational-technology, and other devices.

The host gives a brief Diffie–Hellman key-exchange tutorial: two parties can establish a shared secret over a public channel using public parameters and private values. In the affected code, a function was reportedly passed the size of the generator (G) twice, instead of using the size of the prime (P) for the second argument. This limited the prime to one byte rather than the intended much larger size, sharply reducing the possible shared secrets. The resulting secret was effectively four.

The host treats this as a distinct implementation error—not a consequence of the I-mudhra certificate issue—and warns that similar coding mistakes can undermine cryptographic protections in devices that may be difficult to update.

Sponsored product segment

The video includes a sponsorship for Wiz Code. The host describes it as combining traditional and AI-assisted static application security testing (SAST), then using cloud and runtime context to prioritize findings. It can provide details about where a bug occurs and, through a “red agent,” attempt to exploit a finding in a configured environment and show the attack path. The host says one example reduced 32,000 traditional SAST findings to 503.

Guides and analysis covered

• A plain-language explanation of HTTPS certificate chains, root CAs, intermediate CAs, and certificate revocation.
• A short tutorial on Diffie–Hellman key exchange and how incorrect parameter sizing can weaken it.
• A suggested check using the mentioned test site to see whether local tools trust the affected I-mudhra certificate chain.

Main speakers and sources

• Main speaker: The host of the Low Level channel; no name is given in the subtitles.
• Referenced sources: An XKCD comic; public social-media posts and reported vulnerability details concerning I-mudhra and GoAhead; the I-mudhra certificate test site.
• Sponsor: Wiz, with a segment describing Wiz Code.