There is a massive revocation of TLS certificates from a variety of CAs, mistakenly generated on a 63-bit RNG instead of 64-bit
Three days ago in the mailing list mozilla.dev.security.policy published a message about a massive violation in the generation of TLS-certificates. The investigation showed that several certification centers suffered, including GoDaddy , Apple and Google . The total number of incorrect certificates exceeds 1 million, and maybe much more. GoDaddy originally named the figure of 1.8 million certificates, and then reduced the estimate by two orders of magnitude, to 12,000. An Apple representative called the figure 558,000 certificates .
The bottom line is that all CA victims used an open source EJBCA PKI solution with incorrect settings, which resulted in using random numbers from 63-bit space for consecutive certificate numbers, which violates the CA / B Forum 's minimum entropy requirements (64 bits).
The difference between 2 63 and 2 64 exceeds 9 quintillion, that is, 9 Ă— 10 18 , this is a very significant number (although the difference is only two times). All certificates must be revoked. The SSL.com and GoDaddy procedure will take 30 days, others may have about the same time, although they are required by RFC5280 to revoke incorrect certificates within five days. But they obviously do not have time to invest in the standard.
How did this happen? A preliminary analysis showed that all certificates have the length of the corresponding field exactly 64 bits: no more, no less. If the RNG issues 64 bits of entropy and all certificates are exactly 64 bits, then at first glance, everything is fine. But the problem is that according to RFC5280 :
The popular EJBCA PKI system, which is used by many CAs, generates 64-bit numbers by default and simply resets the most significant bit for certificate numbers. That is, in fact, their RNGs produce 63-bit numbers, which is why many CAs suffered.
The 64-bit default requirement for RNGs was not formulated from scratch, but after the 2008 hack , when a cluster of 200 PlayStation 3 game consoles generated clashes for MD5 hash, which allows you to create a fake certification authority that all browsers and operating systems will trust .
In 2012, this trick was used by the American cyber weapon Flame , infiltrating the Windows Update mechanism.
However, now SHA256 is used for generation, it is a more modern algorithm in comparison with MD5, so the minimum requirement of 64 bits is taken more likely for preventive purposes. Experts say that now there are no chances to find collisions in 63 bits and somehow exploit the error found with incorrect certificates.
But the recall of millions of certificates is a headache for the system administrators of many companies.
The loss of 1 bit of entropy is not so terrible, but someone somewhere can find a vulnerability that steals another 1-2 bits, and so on. So all such vulnerabilities need to be fixed immediately.
The bottom line is that all CA victims used an open source EJBCA PKI solution with incorrect settings, which resulted in using random numbers from 63-bit space for consecutive certificate numbers, which violates the CA / B Forum 's minimum entropy requirements (64 bits).
The difference between 2 63 and 2 64 exceeds 9 quintillion, that is, 9 Ă— 10 18 , this is a very significant number (although the difference is only two times). All certificates must be revoked. The SSL.com and GoDaddy procedure will take 30 days, others may have about the same time, although they are required by RFC5280 to revoke incorrect certificates within five days. But they obviously do not have time to invest in the standard.
How did this happen? A preliminary analysis showed that all certificates have the length of the corresponding field exactly 64 bits: no more, no less. If the RNG issues 64 bits of entropy and all certificates are exactly 64 bits, then at first glance, everything is fine. But the problem is that according to RFC5280 :
Serial Number "Serial Number"The requirement of a positive number means that the most significant bit cannot be set. If it is installed, it cannot be used directly as the serial number of the certificate.
')
The sequential number must be a positive integer assigned by the CA to each certificate. It must be unique for each certificate issued by a specific CA (i.e. the publisher’s name and sequential number identify a unique certificate).
CAs should strictly control the procedure for publishing CERT, so that the serial number will never be a negative integer. The above unique requirements suggest that consecutive numbers may be long integers. CEPT users must be able to process the value in the “serialNumber” subfield of up to 20 octets (inclusive). The following CAs should not use values ​​in the “serialNumber” subfield with a length of more than 20 octets.
The popular EJBCA PKI system, which is used by many CAs, generates 64-bit numbers by default and simply resets the most significant bit for certificate numbers. That is, in fact, their RNGs produce 63-bit numbers, which is why many CAs suffered.
The 64-bit default requirement for RNGs was not formulated from scratch, but after the 2008 hack , when a cluster of 200 PlayStation 3 game consoles generated clashes for MD5 hash, which allows you to create a fake certification authority that all browsers and operating systems will trust .
In 2012, this trick was used by the American cyber weapon Flame , infiltrating the Windows Update mechanism.
However, now SHA256 is used for generation, it is a more modern algorithm in comparison with MD5, so the minimum requirement of 64 bits is taken more likely for preventive purposes. Experts say that now there are no chances to find collisions in 63 bits and somehow exploit the error found with incorrect certificates.
But the recall of millions of certificates is a headache for the system administrators of many companies.
The loss of 1 bit of entropy is not so terrible, but someone somewhere can find a vulnerability that steals another 1-2 bits, and so on. So all such vulnerabilities need to be fixed immediately.
Source: https://habr.com/ru/post/443598/
All Articles