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.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...