A reckless stunt by an Indian programmer nearly brought down the global internet yesterday.

The past 48 hours are arguably the most "united" moment for the global internet — a large number of websites have launched urgent maintenance, many games have suspended their services, and all teams are closing in to fix bugs.

One of the reasons you most likely guessed is the vulnerability in PHP (a web development language). Even the Japanese government has specifically posted a notice about this issue...

Japan is usually seen as a region where hackers treat it as a beginner's practice zone, and even they are panicking now, which shows how urgent this situation is.

I even saw a joke saying that the Japanese restaurants that closed for rectification these days serve the most authentic food, so now I have no choice but to go to Sushiro. (just kidding)

In addition, Japan's game and ACG fields are also the hardest hit areas in this maintenance wave, since a lot of game login systems, malls and data interfaces rely on PHP...

For example, for the Chinese server of *Final Fantasy XIV*, it is normal that you cannot log in temporarily with the old launcher, you can access the game by switching to the new launcher or WeGame.

So, teams that use PHP probably have to pull all-nighters these days to apply patches...

Jokes aside, this PHP vulnerability is definitely not a trivial issue.

As a programming language widely used for website development and web backends, PHP has a far stronger presence than most people imagine.

Not only are around 70% of websites worldwide using PHP, but the two vulnerabilities discovered this time are extremely dangerous. According to the official PHP security announcement, the CVSS score (Common Vulnerability Scoring System, full score 10) of this incident is 9.2 points...

These are dangerous remote code execution (RCE) vulnerabilities that can be exploited without identity authentication. The consequences range from tampered website content and stolen user data, to the server being fully taken over, or even the entire service being paralyzed.

Fortunately, as things stand, the situation has not gotten out of control.

The PHP development team has urgently released repair patches. For systems that are too late to apply patches, some organizations have chosen to directly disconnect their networks — before the issue is fully fixed, the safest website is the one that temporarily does not exist...

But on the other hand, the "PHP vulnerability" at least has a relatively clear solution.

Another bug that broke out on the internet these days has no easy end to fix. This is not something that can be solved by the official releasing a single round of patches, and to some extent, we need to check and fix it by ourselves.

Yes, some of you may have heard that an Indian company set the private key value of their internet digital certificate (equivalent to the password of the certificate) to several numbers under 255 such as "4", "56" and "155"...

What's more troublesome is that these problematic certificates have already entered the global internet trust system, and they have a huge impact on us. For example, even 6 days after the incident, the built-in browser in WeChat client can still connect to the problematic emsign digital certificate...

To explain a little bit, the internet is a connected network, but when our mobile phone connects to a website / APP / server, it does not directly pull a line from the phone to the target. Countless switches and routers act as nodes in the middle to help you redirect and transmit data packets on your behalf.

In the traditional network traffic environment, if any intermediate node is implanted with malicious software, it can secretly monitor the plaintext data transmitted between you and the website without you noticing.

To solve this problem, the modern internet has introduced digital certificates to encrypt traffic. As long as your browser prompts that the connection is safe, it means that your communication is encrypted.

Only you and the server that finally receives the information can see the plaintext of the data. Every hop and every routing node in the middle can only forward the data on behalf of you — they only know that they forwarded a data packet, but cannot view the specific content of the data.

This encryption system is called TLS. To ensure the smooth operation of this system, a fully trusted third-party institution is required to act as an intermediary to issue digital certificates for websites — you can ask AI assistants for the specific details, we will not expand on it due to space limitations.

Then here comes the problem. eMudhra, the main party of this incident, is one of such "intermediary" institutions. The intermediate CA certificates it holds can issue digital certificates for almost any website, and the issued certificates are trusted by all internet-connected devices.

As a result, the private keys of these "intermediary certificates" themselves have problems. Anyone who masters this vulnerability can issue certificates for any website in the name of eMudhra. Even fake websites can get a legal and trusted certificate.

Theoretically, the private key of this batch of eMudhra certificates is 384 bits long, with 2^384 combinations. Normally, brute-force attacks that run thousands of trillions of times cannot crack it...

But according to the report of security researchers, for this batch of eMudhra private keys, all the previous bytes are set to 0, and only the last 1 byte has actual entropy, that is, random numbers. The number that 1 byte can store corresponds to the decimal system, leaving only 256 possibilities...

In other words, if you try numbers one by one starting from 1, you can get the private key after at most 255 attempts. What's more ridiculous, one of the private keys is exactly the number 4.

If you trace back along the problematic CA certificates, you will find that eMudhra has also carried out global cross-signature authentication with some old root certificate institutions. That means, through these almost unprotected intermediate certificates, attackers can further extend their reach to other corners of the global internet.

If your browser and the devices you are using still use the old certificates mentioned in the announcement, others have the opportunity to forge digital certificates, hide in the upper nodes of your network, intercept your communication traffic, and steal your data.

They can not only monitor all your chat records and life trajectories, but also forge false data in some scenarios with weak encryption. For example, a pop-up message saying "You won a prize" may suddenly appear when you are normally using an app, and if you believe it, you may be scammed.

Therefore, after the incident became public on October 21, eMudhra's stock price directly triggered a 20% limit down in the Indian market...

As soon as the vulnerability was exposed, major browsers and root certificate projects immediately entered the "disconnect the network" mode —

Starting as early as the 17th, companies including Chrome, Firefox, Apple and Microsoft have stopped trusting the relevant certificates under eMudhra at the system level. Google even announced that it will remove the root certificates that issued these intermediate CAs from Chrome's trusted root certificate store.

If you are worried, there is a website called emudhra.we-have-a-problem that can test whether your browser is affected.

I tested it around and found that Apple has revoked all certificate support at the system level (Safari) on the 21st (and restored three on the 22nd), while Firefox has completely revoked the trust of 12 certificates. WeChat's action in this regard is indeed a bit slow...

Besides this point, the reason why I say the problem caused by "internet certificates" ultimately requires us to check and repair by ourselves is that the operations of these large companies above can only ensure that your mobile phone and computer are safe.

In fact, in our internet environment, there are a large number of servers, IoT devices and background programs that do not have the independent certificate blacklist hot update mechanism like Chrome and Firefox.

For example, the cameras, smart home terminals and smart speakers in our homes generally rely on the CA certificate package in the Linux system, the CA trust store that comes with the software, or the root certificate pre-installed in the firmware.

In other words, if the operation and maintenance personnel do not update the system or push new firmware, some old Linux systems, embedded IoT devices, industrial control equipment and unattended intranet servers will still trust the problematic certificates, which is equivalent to running naked under the risk of being hijacked.

The follow-up work of this legacy problem of the trust store will be very long. Countless multinational supply chains, old servers and IoT devices around the world will probably keep people busy for a long time.

What's more ridiculous is that such a huge trouble may only come from a very low-level human error.

The latest statement about the eMudhra digital certificate incident is that the technicians of eMudhra "made a careless mistake", they forgot to replace the weak key used for migration testing after the migration was completed, and finally the key flowed into the production environment. It is really exasperating...