Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:30 PM
Tim Callan
Tim Callan
Connect Directly
E-Mail vvv

It's Time to Improve Website Identity Indicators, Not Remove Them

Why Google and Mozilla are wrong about the benefits of Extended Validation certificates that aim to prevent fraud and protect user privacy.

We're seeing much effort toward protecting consumer privacy worldwide — in Congress, with the GDPR, and other initiatives. But how can we protect web privacy without establishing the identity of the websites users visit? Extended Validation (EV) certificates are a highly effective way to provide this information and protect consumers.

However, Google and Mozilla have announced that they are eliminating interface indicators showing that a site has been authenticated with an EV certificate, arguing that the EV user interface does not protect users as intended. We believe this is a mistake and encourage them to come up with innovative ways to use EV data rather than hide it. Here are four reasons why.

Reason 1: EV has helped protect web identity and privacy for a decade.
For years, websites that want to show users their confirmed identity have gone through the EV process when buying SSL/TLS certificates from public certificate authorities (CAs). Similar to banking rules, EV certificates include encrypted, in-depth information about the business and the owner. Financial sites, online retailers, hospitals, and other businesses use them to protect their customers and their brands from phishers. The most common alternative to EV certificates is Domain Validation (DV) certificates, which contain no identity or contact information.

For the past decade, browsers have distinguished websites that use EV certificates with a distinctive indicator. This indicator conveys very useful information, as the incidence of phishing sites using EV is nearly zero. Once Google and Mozilla remove the EV indicator from their Chrome and Firefox browsers, users will only see a site's URL, just as they do for DV sites. We believe this change is based on flawed analyses.

Reason 2: Phishing on DV sites is skyrocketing, and users are safer with EV.
Until recently, almost all phishing and malware was on unencrypted http sites that displayed a neutral UI. Users were trained to "look for the lock symbol" for security. But when Google and Mozilla incentivized websites to move to encryption through their "Not Secure" warnings, phishers' motivation to include free, anonymous DV certificates increased. Predictably, virtually all phishing has now moved to DV-encrypted websites that display the lock symbol.

Browser companies contend that EV marks are unnecessary because end users don't understand them. However, not all users are alike, and it would be more accurate to say "Not all users understand them." For those who do understand, these browsers have taken away the opportunity to know when a site comes from a company with a known, verified identity.

Reason 3: EV indicators offer intuitive, proactive security.
Without the EV identity browser indicator, users are back to looking at the URL and trying to puzzle out if it's legitimate or not. Or, if they're lucky enough that the browser identifies a phishing site as such, they may receive a warning. URLs are notoriously difficult to parse, with many phishing techniques building upon the ability to create a confusing URL. Take the example of 2018's massive British Airways breach, which compromised 380,000 customers' personally identifiable information and payment data and was enabled by the use of the deceptive URL baways.com.

Some say the EV UI should go away because users don't understand the specific organization information that's displayed. We believe this is a reason to improve the indicator — not remove it.

An improved EV indicator would have the potential to offer proactive security, protecting users before they share data. Browser phishing filters are reactive, meaning some users will of necessity get hurt before the filters can find them. And to evade the filter, a banned phisher can simply shut down the offending site and then anonymously run the same scam from a new domain.

Some industry watchers object that if user trust in EV sites increases, then phishers will simply get EV certificates. That's possible, but once a phisher with an EV certificate uses it for a scam, the issuer will surely revoke the certificate and add the organization's name and domains to its flag list — blocking their ability to get another EV certificate from that CA forever. Therefore, sustainable, high-volume phishing schemes become unsustainable using EV certificates.

Reason 4: The industry needs an evolving EV standard.
Member companies of the CA Security Council were among those that put together the original EV specification, envisioning a standard that would continue to evolve and improve. To combat phishing and raise identity standards for websites, we believe browser companies should work together to develop common security indicators and work with CAs to help train and educate users on security best practices. 

As phishing attacks continue to increase and evolve, our identity and security standards — and user education — must as well. EV certificates represent a great opportunity for innovation and collaboration that will benefit web users and the whole industry.

 Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Developers: The Cause of and Solution to Security's Biggest Problems."

Senior Fellow Tim Callan contributes to Sectigo's standards and practices, industry relations, product roadmap, and go-to-market strategy. A founding member of the CA/Browser Forum, Tim has more than 20 years of experience as a product and strategic marketing leader for ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Guru
10/24/2019 | 5:44:59 PM
Not of Concern
I have to aree with Google and Mozilla on this one. While EV SSL do a more through checking on the purchaser during inital setup they do little to increase user privacy or confidence in a website.  There is no encryption difference between EV and DV certs. An evildoer could just as easilyy purchase an EV cert with false information if they own the domain they are phishing from (which in most cases they do with similarish names) it just takes a few days vs. a few minutes to obtain the certificate.  If we want to really provide users with better privacy a focus would be placed on securing domains with DNSSEC and making it easier for users to utilize protocols like DNSCrypt/DoH/DoT and providing more secure no log DNS servers.  Use of those tools will almost completely eliminate phishing all together as the problem with DNS is that it is unencrypted and unvalidated by default which allows for the malicious redirects in the first place.  In my opinion, the reluctancy to implement these technologies revolves around the fact that ISP's, governments, fill in the blank, all make huge amounts of money data mining our DNS requests as well as using them to track everything regular users do on the internet, they are also used to implement content filtering and access restrictions many places, if privacy is really implemented billions of dollars could be lost.  Mozilla took a lot of heat for being one of the early adopters of DoH/DoT which their browser now supports however, this was/is the right move to increase privacy and security of end users across the board.
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-23
An improper authorization of using debugging command in Secure Folder prior to SMR Oct-2020 Release 1 allows unauthorized access to contents in Secure Folder via debugging command.
PUBLISHED: 2021-04-23
Apache Maven will follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be t...
PUBLISHED: 2021-04-23
In SaltStack Salt 2016.9 through 3002.6, a command injection vulnerability exists in the snapper module that allows for local privilege escalation on a minion. The attack requires that a file is created with a pathname that is backed up by snapper, and that the master calls the snapper.diff function...
PUBLISHED: 2021-04-23
The xmlhttprequest-ssl package before 1.6.1 for Node.js disables SSL certificate validation by default, because rejectUnauthorized (when the property exists but is undefined) is considered to be false within the https.request function of Node.js. In other words, no certificate is ever rejected.
PUBLISHED: 2021-04-22
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is Prior to 6.1.20. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromi...