Below is our recent interview with Kirk Hall, Director Policy and Compliance and Chris Bailey, VP of Strategy at CA Security Council:
Q: Could you provide our readers with a brief introduction to CASC?
A: The CA Security Council (CASC) is comprised of leading global Certificate Authorities that are committed to the exploration and promotion of best practices that advance trusted SSL deployment and CA operations as well as the security of the internet in general. While not a standards-setting organization, the CASC works collaboratively to improve understanding of critical policies and their potential impact on the internet infrastructure.
Membership in the CASC is available to publicly trusted SSL certificate authorities that meet the CASC’s reputation, operation, and security requirements. At a minimum, each member is required to abide by industry standards, such as the CA/Browser Forum’s Baseline Requirements and Network Security Guidelines, and undergo an extensive annual audit.
Q: You’ve recently announced launch of the London Protocol. Tell us more about the initiative.
A: The London Protocol was given its name because it was formally announced at the London face-to-face meeting of the CA/Browser Forum on June 6-7, 2018.
The Protocol is a voluntary initiative among leading Certificate Authorities (CAs) to improve identity assurance and minimize the possibility of phishing activity on websites encrypted with organization validated (OV) and extended validation (EV) certificates, both of which contain organization identity information confirmed by the issuing CA (Identity Certificates).
Following the recent rise in phishing attacks, five certificate authorities (CAs) from CASC developed the London Protocol to reinforce the distinction between Identity Websites and websites encrypted by domain validated (DV) certificates, which lack organization identity and are heavily used by phishers because they are anonymous and can be obtained quickly and in bulk.
Q: How did the London Protocol come about?
A: The web is moving very rapidly to 100% encryption (meaning all websites must use SSL digital certificates or else they will receive browser warnings that are unwelcome to users), which increases user security. However, this requirement of website encryption has driven phishers from unencrypted http sites to encrypted https sites, where they imitate major brands (such as PayPal, Apple, bank sites, etc.) in order to trick users into giving them their password and credit card information.
Phishers have moved to encryption by using anonymous DV (Domain Validated) certificates, which are quick and easy to acquire in bulk. In contrast, recent studies show there is almost no phishing on Identity Websites – those encrypted with OV and EV certificates, which contain identity information about the website owner confirmed by the issuing CA. On the rare occasions when phishing content is found on an OV site (it’s almost never found on EV sites), the cause is usually hacking of the site to post phishing content on a hidden page, and the website owner is unaware the phishing content is there.
Because of these factors, CAs decided to support a common phishing detection engine that will notify an issuing CA if once of its OV or EV certificates is securing a site with phishing content. The issuing CA can then notify its customer and help the customer remove the phishing content (e.g., by giving the customer the location of the content, providing information on hardening of the site, etc.), which will make Identity Websites even safer for users than they are today.
Q: What does “Secure” really mean?
A: Some browser UI security indicators have used the word “Secure” on DV-encrypted phishing websites. The explanation is that the word “Secure” is only meant to say “encrypted,” but is not meant to say the site is safe or trusted for users to visit. Unfortunately, most uses are interpreting the work “Secure” in the browser UI as meaning “safe” or “trusted,” which means they may be more vulnerable to anonymous DV phishing websites marked as “Secure” which display fake login pages for major brand websites.
CASC believes that DV websites should not receive any positive browser UI because they are heavily infested with phishing sites – because https is now a requirement for all websites, and because DV is the absolute minimum encryption level a site can have, it would be better if DV sites are not marked by browsers as “Secure” and receive no positive UI at all.
Q: How will the London Protocol help minimize phishing on websites?
A: First, most browsers provide a strong, positive UI for EV websites, displaying the confirmed name of a company or its brand and the country of operation in a green bar in the UI. This is a signal to users that the website owner is known and has been strongly identified, and therefore is likely to be much safer for users than anonymous DV sites, which include many fake phishing sites.
Second, the London Protocol will help minimize phishing because the identity data inside OV and EV certificates is already relied on by anti-phishing services, such as the Anti-Phishing Working Group, PhishLabs, and even the browser filters themselves. These anti-phishing services already know that an OV or EV website is less likely to have phishing content than an anonymous DV website, plus they can copy and store the identity information and use it later when they encounter other websites at other domains that have the same owner. This is a reputational aspect of Identity Certificates that follows owners across the internet, and is important to user security. The London Protocol will further strengthen the security of OV and EV websites, making it easier for anti-phishing services to do their job.
Q: There are several phases to this initiative. What’s next?
A: Here are the phases as currently planned:
• Phase 1 (June – August 2018): Participating CAs develop Protocol details and research feasibility of implementation and may begin to implement some basic procedures.
• Phase 2 (September – November 2018): Participating CAs apply Protocol concepts to their own customers’ Identity Websites according to their own policies and procedures, share feedback with other participating CAs, refine Protocol as warranted by experience.
• Phase 3 (December 2018 – February 2019): Participating CAs update Protocol policies and procedures and approve plan for uniform policies and procedures to be applied by all participating CAs on a voluntary basis.
• Phase 4 (March 2019) Participating CAs forward report and recommendations to CA/Browser Forum for possible changes to Baseline Requirements.
Every part of the London Protocol today is completely voluntary, as we figure out what’s the best way to eliminate as close to 100% of phishing content from OV and EV websites as possible. Note: this may be the first cooperative effort of this magnitude among competing CAs to improve the SSL certificate ecosystem.
Once we have some experience with our procedures, we will report back to the CA/Browser Forum and discuss whether there are industry improvements we can make to the Forum’s mandatory Baseline Requirements so they would apply to all CAs worldwide. As the internet continues to evolve, CA practices must also evolve and improve, and CASC is at the forefront of looking for new ways to ensure user security.