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.

Risk

10/24/2019
02:30 PM
Tim Callan
Tim Callan
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
timcallan
50%
50%
timcallan,
User Rank: Author
10/25/2019 | 8:18:08 PM
Re: Not of Concern
It's inaccurate to say, "An evildoer could just as easilyy purchase an EV cert with false information if they own the domain they are phishing from..." In fact, that is not the case. EV requires the use of highly effective authentication methods that have remained undefeated in more than ten years of widescale, global production on the most valuable and lucrative online targets. While spoofing a domain name is as easy as coming up with a credible string that is available for registration, the information presented in an EV certificate is highly reliable.

EV certs are here today, they work, and they have an impeccable track record. Let's continue to benefit from them. Let's build on that, not tear it down.
dwrightetc
50%
50%
dwrightetc,
User Rank: Apprentice
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.
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19642
PUBLISHED: 2019-12-08
On SuperMicro X8STi-F motherboards with IPMI firmware 2.06 and BIOS 02.68, the Virtual Media feature allows OS Command Injection by authenticated attackers who can send HTTP requests to the IPMI IP address. This requires a POST to /rpc/setvmdrive.asp with shell metacharacters in ShareHost or ShareNa...
CVE-2019-19637
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixel_decode_raw_impl at fromsixel.c.
CVE-2019-19638
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function load_pnm at frompnm.c, due to an integer overflow.
CVE-2019-19635
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function sixel_decode_raw_impl at fromsixel.c.
CVE-2019-19636
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixel_encode_body at tosixel.c.