- September 07, 2016
- Info notes
WoSign, a Certificate Authority (CA), issued base digital certificates for GitHub and the University of Central Florida, relying only on a user’s mere control of respective subdomains, allowing for a Man-in-the-Middle (MitM) attack. The mismanagement, compromise and manipulation of digital certificate management systems has proven to have serious repercussions on Internet security, which relies heavily on digital certificates. This note provides some background information on CAs and past incidents, an overview of the WoSign incident, and recommendations related to CAs and fraudulent certificates.
Background and Previous Incidents
By definition, CAs are trusted parties that issue digital certificates. Digital certificates employ public key cryptography to prove the ownership and authenticity of an entity, e.g. a website. They are used to enable secure communication by facilitating the encryption of shared data between two communicating parties.
CAs have the power to issue digital certificates for domains even if the digital certificate for a particular domain already exists. This feature pinpoints why CAs are one of the weakest links of information and Internet security. As previous incidents suggest, CAs can be abused either internally by the mismanagement of their service or by a third-party due to a security breach, with severe consequences for Internet security, as demonstrated by these examples:
- In 2012, Trustwave CA, issued a subordinate root certificate to a company, allowing it to issue arbitrary valid certificates on its own, enabling the company to act as a MitM and potentially listen to its staff encrypted traffic from/to known web services.
- In 2011, DigiNotar CA was compromised. The attackers managed to issue themselves a series of certificates for well-known domains. More specifically, they managed to issue a certificate for “google.com”, which was abused in a large scale MitM attack, targeting approximately 300,000 users from Iran.
- Also in 2011, a Comodo trusted partner (Registration Authority - RA) was compromised. This led to the improper issuance of nine certificates for seven different domains (Google, Yahoo, Skype, etc.).
- In 2008, an attacker targeted StartSSL CA and managed to issue four certificates, which were revoked shortly after the attack.
The WoSign Incident and Considerations
In August 2016, Gervase Markham disclosed an issue regarding WoSign’s free certificate service, on Mozilla’s security policy mailing list. The issue was originally identified by a service applicant in 2015. In June 2015, WoSign issued certificates for base domains to a user on the basis of merely controlling a few corresponding subdomains. In WoSign’s case, a successful attack required a user to control a subdomain of the website they aimed to get a certificate for; usually by owning an account to that website, which gave them control of a “user.website.com” type of subdomain.
The applicant initially applied and received a certificate for “med.ucf.edu”. Then, after accidentally applying for “www.ucf.edu”, their request was approved. In order to confirm the issue, they employed their control over their GitHub account (“user.github.com” and “user.github.io”) to request a certificate for “github.com”, “github.io” and “www.github.io” respectively, which they eventually received.
Interestingly, the user reported the issue to WoSign but by only disclosing the improper validation and issuance of the GitHub certificate, which was then revoked. The second certificate “www.ucf.edu” remained active for over a year, until the user reported it to Google.
The fact that “www.ucf.edu” certificate was not revoked raises multiple concerns: It implies that WoSign did not conduct (or could not conduct) a research in its database for similar improperly issued certificates, WoSign did not inform Mozilla about the improper issuance, and enabled attackers to potentially perform a MitM for a span of a year.
CAs have a lot of power and are considered to be trusted-parties; however, a lot of CAs have proved to be flawed and risky in the way they operate. This highlights a general structural problem regarding the certificate management system. CAs often rely on very little proof to issue certificates for known domains, as in the WoSign case. Being a single point of failure makes them an ideal target for attackers, and resultant security breaches will in most cases have a high impact. Until a better solution is found to replace or restructure the current certificate management system, a collective effort will be required by all concerned parties to ensure Internet security and avoid the next security incident related to CAs and fraudulent certificates.
ENISA has published guidelines and a standardisation in the field of Trust Service Providers that cover a wide spectrum of considerations and requirements thereof. In accordance with them, the main recommendations for CAs are the following:
Due Diligence. CAs and their trusted partners must do their due diligence and carefully vet the process of issuing digital certificates. They must perform proper background checks before issuing any type of digital certificate, especially for well-known domains, which are mostly targeted by potential attackers.
Security Policies. CAs should establish adequate security policies according to standards, e.g. WebTrust, and CA security requirements.
Security Audits and Incident Response. CAs should be considered as important as critical infrastructure and must follow all the known and proper procedures to avoid security breaches, e.g. perform regular external and independent security audits, and be able to quickly respond to them as soon as they occur.
Accountability. CAs need to keep logs of all certificates they issue (and to whom), in order to be able to investigate any kind of incident related to the issuance of a certificate.
Internal Auditing. In the case of an improper issuance, CAs must as soon as possible revoke the fraudulent certificate/s and perform internal checks for identifying similar incidents.
No Shortcuts in Issuing Certificates. CAs must keep up with their high level of responsibility, do not take shortcuts in their certificate issuance procedure and refrain from aiming usability over security.
Transparency. All CAs are encouraged to be fully transparent regarding the certificates they issue, by adopting initiatives like Google’s Certificate Transparency Project, and writing the certificates they issue in publicly accessible, append-only, certificate logs to be easily verifiable.
For Browser Makers
Rule out Misbehaving CAs. Browser makers hold a lot of power in their hands and they should contribute to the security of the Internet. Browser makers should be more stringent in the root certificates they bundle with their browsers and rule out misbehaving or breached CA authorities until trust is restored.
For Website Owners
Consider HTTP Public Key Pinning (HPKP). HPKP is a security feature that prevents fraudulent certificates from being accepted by the browser. Essentially, when a user connects to a website for the first time (assuming they established a secure and authentic session), the website instructs the browser to remember the fingerprint of its certificate. Then, on subsequent connections, the website sends the HPKP header and the browser compares the website’s certificate fingerprint to the previously “pinned” fingerprint. If they do not match, then the browser should deny the connection.
*Having said that, website owners should be attentive towards HPKP. They need to understand the technology before using it since there are some risks entailing its usage that must be taken under consideration. A good summary of the issues related to HPKP is provided by Qualys.
* We would like to thank Pieter Rogaar for his feedback on the risks related to HPKP.
About “Info Notes” from ENISA
With the “Info Notes” series ENISA aims to give interested readers some background information and recommendations about NIS related topics. The background information and recommendations derived from past experiences and common sense, and should be taken as starting points for discussions on possible courses of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more about the “Info Notes” series (firstname.lastname@example.org).