- Apr 26, 2017
- 89
Researcher Hanno Böck has tricked Symantec into revoking TLS certificates by falsely claiming that their private keys had been compromised. Comodo was also targeted, but the company did not fall for the same ruse.
Certificate authorities (CAs) are required to revoke certificates whose private keys have been compromised within 24 hours. Keys are often inadvertently exposed by certificate owners and previous research by Böck showed that while it often takes companies more than 24 hours, ultimately they do revoke compromised certificates.
Böck then decided to check if CAs ensure that an allegedly compromised private key actually belongs to a certificate before revoking it.
The researcher set up a couple of test domains and ordered free, short-term certificates for them from Comodo and Symantec’s RapidSSL. He then created fake private keys for the certificates and attempted to trick Symantec and Comodo into revoking them by providing the forged keys.
In order to increase his chances of success, Böck searched the web for private keys that were actually compromised and added them to a Pastebin post along with his forged keys. He then informed Comodo and Symantec about the “compromised” keys and asked them to revoke the certificates.
While Comodo did notice the fake keys among the ones that were actually compromised, Symantec informed him that all the certificates whose private keys were in the Pastebin post, including the fake ones apparently associated with the researcher’s test domains, had been revoked.
“No harm was done here, because the certificate was only issued for my own test domain. But I could’ve also fake private keys of other people's' certificates. Very likely Symantec would have revoked them as well, causing downtimes for those sites” Böck explained.
The researcher was also displeased with the fact that Symantec did not provide a reason for revoking the certificates, which makes it difficult for domain owners to learn from mistakes and improve their processes. Symantec insisted that the keys associated with Böck’s certificates had been compromised, even after he pointed out that the certificates had actually been revoked based on forged keys.
“Symantec did a major blunder by revoking a certificate based on completely forged evidence. There’s hardly any excuse for this and it indicates that they operate a certificate authority without a proper understanding of the cryptographic background,” Böck said.
After the researcher made his findings public, Symantec published a blog post promising to improve its processing of third-party revocation requests.
“First, a gap was identified in the public and private key matching process where keys are verified during the revocation request procedure,” Symantec said. “We performed a modulus comparison, a necessary part of this verification process, but it was incomplete as other parameters in the keys were not checked. Once we became aware of this, we immediately corrected the procedure. We are not aware of any instances where there was customer impact as a result of this process gap other than the test scenario run by the reporting researcher.”
“Secondly, we are reviewing how we communicate with customers during the 3rd party revocation request process to be more consistent and transparent with certificate owners,” it added.
Google and Mozilla are both displeased with Symantec, its subsidiaries and its partners regarding the improper issuance of certificates. There has been a lot of debate over the past few months about how Symantec should be penalized, with the security firm making another counterproposal this week.
Source: Symantec Tricked Into Revoking Certificates Using Fake Keys | SecurityWeek.Com
Certificate authorities (CAs) are required to revoke certificates whose private keys have been compromised within 24 hours. Keys are often inadvertently exposed by certificate owners and previous research by Böck showed that while it often takes companies more than 24 hours, ultimately they do revoke compromised certificates.
Böck then decided to check if CAs ensure that an allegedly compromised private key actually belongs to a certificate before revoking it.
The researcher set up a couple of test domains and ordered free, short-term certificates for them from Comodo and Symantec’s RapidSSL. He then created fake private keys for the certificates and attempted to trick Symantec and Comodo into revoking them by providing the forged keys.
In order to increase his chances of success, Böck searched the web for private keys that were actually compromised and added them to a Pastebin post along with his forged keys. He then informed Comodo and Symantec about the “compromised” keys and asked them to revoke the certificates.
While Comodo did notice the fake keys among the ones that were actually compromised, Symantec informed him that all the certificates whose private keys were in the Pastebin post, including the fake ones apparently associated with the researcher’s test domains, had been revoked.
“No harm was done here, because the certificate was only issued for my own test domain. But I could’ve also fake private keys of other people's' certificates. Very likely Symantec would have revoked them as well, causing downtimes for those sites” Böck explained.
The researcher was also displeased with the fact that Symantec did not provide a reason for revoking the certificates, which makes it difficult for domain owners to learn from mistakes and improve their processes. Symantec insisted that the keys associated with Böck’s certificates had been compromised, even after he pointed out that the certificates had actually been revoked based on forged keys.
“Symantec did a major blunder by revoking a certificate based on completely forged evidence. There’s hardly any excuse for this and it indicates that they operate a certificate authority without a proper understanding of the cryptographic background,” Böck said.
After the researcher made his findings public, Symantec published a blog post promising to improve its processing of third-party revocation requests.
“First, a gap was identified in the public and private key matching process where keys are verified during the revocation request procedure,” Symantec said. “We performed a modulus comparison, a necessary part of this verification process, but it was incomplete as other parameters in the keys were not checked. Once we became aware of this, we immediately corrected the procedure. We are not aware of any instances where there was customer impact as a result of this process gap other than the test scenario run by the reporting researcher.”
“Secondly, we are reviewing how we communicate with customers during the 3rd party revocation request process to be more consistent and transparent with certificate owners,” it added.
Google and Mozilla are both displeased with Symantec, its subsidiaries and its partners regarding the improper issuance of certificates. There has been a lot of debate over the past few months about how Symantec should be penalized, with the security firm making another counterproposal this week.
Source: Symantec Tricked Into Revoking Certificates Using Fake Keys | SecurityWeek.Com
