We need to know who we’re interacting with online – who electronically signed that document, who really sent that email, who’s behind this site I’m about to log into. The need for that assurance, knowing that who we’re interacting with is actually who they’re saying they are, has never been greater.
For years, EV SSL/TLS Certificates – that is, certificates that not only encrypt the browser-server connection but also include the site operator’s verified identity – have been one way to address this problem, one way to show the identity behind the website. In order to get this type of “identity certificate”, the domain owner must go through a strict vetting process that not only verifies that they control the domain, but also information about the company’s identity, such as registered name, operational existence, physical location, and more. If a site was using an EV Certificate, the expectation was that the site was actually run by that company and site visitors could see who was behind the site (if they knew where to look, which I touch upon later in this article).
However, nothing is perfect and some incidents came to light earlier this year that pointed out some flaws in the EV system, with both the verification processes and how the identity information is displayed, that could be leveraged to acquire EV Certificates to mislead site visitors. We discussed these incidents in a past post, along with why we think EV will always have value – that having verified company information available to site visitors will always have value, and how there is room for improvement from all parties involved (both CAs like us and the browsers who control the UI).
I won’t rehash those arguments here; instead, I want to give an update on some of the improvement efforts we’re making with our fellow CA Security Council (CASC) members and offer up some additional discussion points about how this identity information can be consumed by site visitors.
How the London Protocol Is Improving Identity assurance
Five CAs from the CA Security Council recently launched the London Protocol, a multi-phase initiative aimed at improving identity assurance and minimizing phishing on identity websites through increased inter-CA communication, enhanced identity validation, and greater assistance to customers whose sites have been compromised.
Let’s start with the proactive portion, where we’re trying to prevent malicious actors from acquiring identity certificates for phishing sites in the first place. Clearly, this is the ideal approach – let’s stop this problem before it even starts. For this, the members of the London Protocol are revisiting how we validate companies before issuing certificates.
Company vetting procedures are already strictly regulated by CA/Browser Forum Baseline Requirements, but the CASC is piloting additional measures that will make it more difficult to acquire identity certificates for malicious purposes. A major component of this will be increased communication between the member CAs regarding suspicious orders – basically, giving each other a heads up whenever we encounter something “phishy.” We hope this will prevent “CA shopping”, where a phisher will put in applications with every CA in hopes of slipping through the cracks somewhere. Another element involves more research into the applicant, including looking to see if their company information, the company contacts, or any domains in their certificate request have been flagged for phishing, which might indicate that this person is a repeat offender.
The member CAs are also planning a more hands on approach for helping customers deal with phishing activity on sites already using identity certificates (e.g., if a sub-directory has been hacked and the content has been altered to be used for phishing). We have developed a new portal that collects from a variety of phishing alert services (e.g., Google Safe Browsing, Anti-Phishing Working Group, and more) that will alert us when a certificate we’ve issued is associated with a site that’s been compromised. We can then notify and work with the customer to remedy the situation (note: we will not automatically revoke the certificate just because it is flagged).
As for how these changes will be implemented, the first phase of the London Protocol is essentially a trial run. The participating CAs will incorporate the concepts into their policies and procedures and then continue to refine and standardize the changes over the second half of this year. Feedback and recommendations from improved vetting checks will then be presented to the CA/Browser Forum as possible changes to the Baseline Requirements and the EV Guidelines.
One last note on the London Protocol. I realize that nothing is perfect and these improvements are not going to magically put an end to phishing on identity websites. We’ve said it before and we’ll say it again – EV Certificates alone cannot, and will not, put an end to phishing - but I am hopeful about the improvements we’re making. I think the past few months have revealed some gaps in our system (and by “our”, I mean both CAs and browsers alike) and it’s important to me that we are taking active steps to close them.
Improvement Needed All Around – The Role of Browser Treatments and How Identity Information Is Displayed
This brings me to my next point and, in my opinion, what should be a key part of this discussion - the CAs are working on improving our validation procedures so visitors can trust identity websites, but that’s all for naught if this identity information isn’t accessible to site visitors or they don’t know what it means. I would love to see some discussion from the browsers about user interface and how certificate information is presented. I see two main areas for improvement here:
- Standardization – currently every browser takes a different approach to how they display certificate information and it’s not uncommon for these appearances to change with new version releases. I realize each browser has their own methodologies and branding approaches, so I don’t expect the experiences to ever be identical across them. But, if we want site visitors to consume this identity information, I think some high level consistency around which information is shown and how visitors can view additional details would go a long way.
- What information is shown? – in the majority of browsers, EV Certificates display the registered company name and the country, but is this the best information to show? Is it granular enough? What if there are multiple instances of a company name in the same country? Likewise, does showing the country where the business is registered actually help anyone? Do users even know what that country abbreviation means? It’s taking up valuable real estate; could it be replaced with something more helpful instead?
On a similar note, are there other ways to distinguish between sites with identity information and those without? For years, we’ve relied on shoehorning basic info (i.e., company name and country) into the address bar, but is there another treatment to consider? Perhaps something that might be a little more noticeable or easier to understand for non-technical users?
I think we can all agree that site visitors need a way to verify who is running the site and I think identity certificates can play a role in this. I’m happy to be working with my fellow London Protocol members to improve our procedures and make it more difficult for these certificates to be used for harmful purposes.
I also look forward to future discussions in the CA/Browser Forum regarding what other potential improvements we can make on both the CA and browser sides to make identity more accessible to site visitors. For example, as Ryan Hurst recently pointed out, CAs are good at verifying information and the information currently used in certificates (e.g., registered company name, location) can be very helpful for consumers should they, say, need to contact the company in case of legal action. While this is a specific example, it begs the bigger question of should we be using this information outside the scope of TLS to provide increased value to web site visitors? This is an exciting question to me and, as the need to know who we’re interacting with online seems to only increase by the day, one I look forward to digging into with my industry peers.
