Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

5133 views
Skip to first unread message

Wayne Thayer

unread,
Aug 12, 2019, 2:31:22 PM8/12/19
to mozilla-dev-security-policy
Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
which is expected to be released on 22-October. Details below.

If the before and after images are stripped from the email, you can view
them here:

Before:
https://lh4.googleusercontent.com/pSX4OAbkPCu2mhBfeleKKe842DgW28-xAIlRjhtBlwFdTzNhtNE7R43nqBS1xifTuB0L8LO979yhpPpLUIOtDdfJd3UwBmdxFBl7eyX_JihYi7FqP-2LQ5xw4FFvQk2bEObdKQ9F

After:
https://lh5.googleusercontent.com/kL-WUskmTnKh4vepfU3cSID_ooTXNo9BvBOmIGR1RPvAN7PGkuPFLsSMdN0VOqsVb3sAjTsszn_3LjRf4Q8eoHtkrNWWmmxOo3jBRoEJV--XJndcXiCeTTAmE4MuEfGy8RdY_h5u

- Wayne

---------- Forwarded message ---------
From: Johann Hofmann <jhof...@mozilla.com>
Date: Mon, Aug 12, 2019 at 1:05 AM
Subject: Intent to Ship: Move Extended Validation Information out of the
URL bar
To: Firefox Dev <firef...@mozilla.org>
Cc: dev-platform <dev-pl...@lists.mozilla.org>, Wayne Thayer <
wth...@mozilla.com>


In desktop Firefox 70, we intend to remove Extended Validation (EV)
indicators from the identity block (the left hand side of the URL bar which
is used to display security / privacy information). We will add additional
EV information to the identity panel instead, effectively reducing the
exposure of EV information to users while keeping it easily accessible.

Before:


After:


The effectiveness of EV has been called into question numerous times over
the last few years, there are serious doubts whether users notice the
absence of positive security indicators and proof of concepts have been pitting
EV against domains <https://www.typewritten.net/writer/ev-phishing/> for
phishing.

More recently, it has been shown <https://stripe.ian.sh/> that EV
certificates with colliding entity names can be generated by choosing a
different jurisdiction. 18 months have passed since then and no changes
that address this problem have been identified.

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
<https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI>.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.



On our side a pref for this
(security.identityblock.show_extended_validation) was added in bug 1572389
<https://bugzilla.mozilla.org/show_bug.cgi?id=1572389> (thanks :evilpie for
working on it!). We're planning to flip this pref to false in bug 1572936
<https://bugzilla.mozilla.org/show_bug.cgi?id=1572936>.

Please let us know if you have any questions or concerns,

Wayne & Johann

Paul Wouters

unread,
Aug 12, 2019, 2:46:38 PM8/12/19
to Wayne Thayer, mozilla-dev-security-policy

> On Aug 12, 2019, at 14:30, Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
> which is expected to be released on 22-October. Details below.

Relocate seems a wrong word here. You are basically removing it. A few geeks will be able to find it at the new location and I wonder why Firefox even bothered to leave it at the new location.

Paul

Peter Gutmann

unread,
Aug 12, 2019, 11:28:07 PM8/12/19
to mozilla-dev-security-policy, Wayne Thayer
Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which
>is expected to be released on 22-October. Details below.

Just out of interest, how are the CAs taking this? If there's no more reason
to pay a substantial premium to enable additional UI bling in browsers, isn't
this going to kill the market for EV certs?

Peter.

Kurt Roeckx

unread,
Aug 13, 2019, 5:12:23 AM8/13/19
to mozilla-dev-s...@lists.mozilla.org
See the original mail for why the indication has been removed in browsers.

But EV is still useful for things like code signing and email. And I
would argue that EV should be the only option for such certificates.


Kurt

Man Ho

unread,
Aug 13, 2019, 5:57:38 AM8/13/19
to dev-secur...@lists.mozilla.org
For EV certificate being useful in email, email client software should
give a special EV treatment to such certificate.  I am not aware of any
email client software that support any special EV treatment at all.  Do
you have more information to share with us?

-- Man Ho

Jakob Bohm

unread,
Aug 13, 2019, 7:24:11 AM8/13/19
to mozilla-dev-s...@lists.mozilla.org
DO NOT SHIP THIS. Revert the change immediately and request a CVE
number for the nightlies with this change included.

That Chrome does something harmful is not surprising, and is no
justification for a supposedly independent browser to do the same.

A policy of switching from positive to negative indicators of security
differences is no justification to switch to NO indication. And it
certainly doesn't help user understanding of any indicator to
arbitrarily change it with 3 days of no meaningful discussion.

The only thing that was insecure with Firefox EV has been that the
original EV indicator only displayed the O= and C= field without enough
context (ST, L). This was used to create tons of uninformed debate
in order to later present that noise as "extensive discusison [SIC] in
the security community about the usefulness of EV certificates".

The change fixes nothing, but instead removes the direct indication of
the validation strength (low-effort DV vs. EV) AND removes the one piece
of essential context that was previously there (country).

If something should be done, it would be to merge the requirements for
EV and OV with an appropriate transition period to cause the distinction
to disappear (so at least 2 years from new issuance policy). UI
indication should continue to distinguish between properly validated OV
and the mere "enable encryption with no real checks" DV certificates.
Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Mirro

unread,
Aug 13, 2019, 11:11:58 AM8/13/19
to mozilla-dev-s...@lists.mozilla.org
在 2019年8月13日星期二 UTC+8下午5:57:38,Man Ho写道:
There are only EV SSL Guideline and EV CS Guideline. I don't know any other EV Guideline for email certificate.
Besides, EV certificate are only issued for organization subscribers.

Thanks,
Mirro

Daniel Marschall

unread,
Aug 13, 2019, 8:27:31 PM8/13/19
to mozilla-dev-s...@lists.mozilla.org
I share the opinion with Jakob, except with the CVE. Please remove this change. It is unnecessary and kills the EV market.
But if you insist on keeping that UI change, maybe you can at least give the lock symbol a different color if it is an EV cert?

Peter Gutmann

unread,
Aug 13, 2019, 9:41:16 PM8/13/19
to mozilla-dev-s...@lists.mozilla.org, Daniel Marschall
Daniel Marschall via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>I share the opinion with Jakob, except with the CVE. Please remove this
>change. It is unnecessary and kills the EV market.

And that was my motivation for the previous question: We know from a decade of
data that EV certs haven't made any difference to security. The only thing
they've affected is CA's bottom line, since they can now go back to charging
1990s prices for EV certs rather than $9.95 for non-EV certs. Removing the UI
bling for the more expensive certs makes sense from a security point of view,
but not from a business point of view: "it kills the [very lucrative] EV
market".

It'd be interesting to hear what CAs think of this. Will the next step be EEV
certs and a restart of the whole cycle, as was predicted when EV certs first
came out?

Peter.

Peter Bowen

unread,
Aug 14, 2019, 12:17:54 PM8/14/19
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> A policy of switching from positive to negative indicators of security
> differences is no justification to switch to NO indication. And it
> certainly doesn't help user understanding of any indicator to
> arbitrarily change it with 3 days of no meaningful discussion.
>
> The only thing that was insecure with Firefox EV has been that the
> original EV indicator only displayed the O= and C= field without enough
> context (ST, L). The change fixes nothing, but instead removes the direct
> indication of
> the validation strength (low-effort DV vs. EV) AND removes the one piece
> of essential context that was previously there (country).
>
> If something should be done, it would be to merge the requirements for
> EV and OV with an appropriate transition period to cause the distinction
> to disappear (so at least 2 years from new issuance policy). UI
> indication should continue to distinguish between properly validated OV
> and the mere "enable encryption with no real checks" DV certificates.
>

I have to admit that I'm a little confused by this whole discussion. While
I've been involved with PKI for a while, I've never been clear on the
problem(s) that need to be solved that drove the browser UIs and creation
of EV certificates.

On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before and
after. For example, "It used to take 10 minutes for the fire sprinklers to
activate after sensing excessive heat in our building. With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long before
it spreads."

If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view chains,
etc), what user experience problem would you be solving by adding
information about certificates to the UI?

Thanks,
Peter

(speaking only for myself, not my employer)

Jakob Bohm

unread,
Aug 14, 2019, 1:16:18 PM8/14/19
to mozilla-dev-s...@lists.mozilla.org
On 14/08/2019 18:18, Peter Bowen wrote:
> On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> A policy of switching from positive to negative indicators of security
>> differences is no justification to switch to NO indication. And it
>> certainly doesn't help user understanding of any indicator to
>> arbitrarily change it with 3 days of no meaningful discussion.
>>
>> The only thing that was insecure with Firefox EV has been that the
>> original EV indicator only displayed the O= and C= field without enough
>> context (ST, L). The change fixes nothing, but instead removes the direct
>> indication of
>> the validation strength (low-effort DV vs. EV) AND removes the one piece
>> of essential context that was previously there (country).
>>
>> If something should be done, it would be to merge the requirements for
>> EV and OV with an appropriate transition period to cause the distinction
>> to disappear (so at least 2 years from new issuance policy). UI
>> indication should continue to distinguish between properly validated OV
>> and the mere "enable encryption with no real checks" DV certificates.
>>
>
> I have to admit that I'm a little confused by this whole discussion. While
> I've been involved with PKI for a while, I've never been clear on the
> problem(s) that need to be solved that drove the browser UIs and creation
> of EV certificates.

EV was originally an initiative to make the CAs properly vet OV
certificates, and to mark those CAs that had done a proper job.
EV issuing CAs were permitted to still sell the sloppily validated
OV certs to compete against the CAs that hadn't yet cleaned up their
act.

This was before the BRs took effect, meaning that the bar for issuing OV
certs was very low.

To heavihandidly pressure the bad CAs to get in line, Firefox
simultaneously started to display exaggerated and untruthful warnings
for OV certificates, essentially telling users they were merely DV
certificates.

So the intended long term benefit would be that less reliable CAs would
exit the market, making the certificate information displayed more
reliable for users.

The intended short term benefit would be to prevent users from believing
unvalidated certificate information from CAs that didn't check things
properly.

As BRs and audits for OV certs have been ramped up, the difference
between OV and EV has become less significant, while the difference
between DV and OV has massively increased.

Thus blurring the line between OV and EV could now be justified, but
blurring the line between DV and EV can not.



>
> On thing I've found really useful in working on user experience is to
> discuss things using problem & solution statements that show the before and
> after. For example, "It used to take 10 minutes for the fire sprinklers to
> activate after sensing excessive heat in our building. With the new
> sprinkler heads we installed they will activate within 15 seconds of
> detecting heat above 200ºC, which will enable fire suppression long before
> it spreads."
>

It used to be easy for fraudsters to get an OV certificate with untrue
company information from smaller CAs. By only displaying company
information for more strictly checked EV certificates, it now becomes
much more difficult for fraudsters to pretend to be someone else, making
fewer users fall for such scams.

Displaying an overly truncated form of the company information, combined
with genuine high-trust companies (banks, credit card companies) often
using obscure subsidiary names instead of their user trusted company
names for their EV certs has greatly reduced this benefit.



> If we assume for a minute that Firefox had no certificate information
> anywhere in the UI (no subject info, no issuer info, no way to view chains,
> etc), what user experience problem would you be solving by adding
> information about certificates to the UI?

This hasn't been the case since before Mozilla was founded.

But lets assume we started from there, the benefit would be to tell
users when they were dealing with the company they know from the
physical world versus someone almost quite unlike them.

Making this visible with as few (maybe 0) extra user actions increases
the likelihood that users will spot the problem when there is one.

Ryan Sleevi

unread,
Aug 14, 2019, 1:43:55 PM8/14/19
to Jakob Bohm, mozilla-dev-security-policy
On Wed, Aug 14, 2019 at 1:16 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> EV was originally an initiative to make the CAs properly vet OV
> certificates, and to mark those CAs that had done a proper job.
> EV issuing CAs were permitted to still sell the sloppily validated
> OV certs to compete against the CAs that hadn't yet cleaned up their
> act.
>
> This was before the BRs took effect, meaning that the bar for issuing OV
> certs was very low.


> To heavihandidly pressure the bad CAs to get in line, Firefox
> simultaneously started to display exaggerated and untruthful warnings
> for OV certificates, essentially telling users they were merely DV
> certificates.
>
> So the intended long term benefit would be that less reliable CAs would
> exit the market, making the certificate information displayed more
> reliable for users.
>

This does not seem to be supported by the statements by Opera, Mozilla, the
KDE Foundation, and Microsoft at the time, so unfortunately, I must point
out that you are either mistaken or being dishonest, or both.

https://web.archive.org/web/20060316082248/http://www.opera.com/security/toronto/
https://dot.kde.org/2005/11/22/web-browser-developers-work-together-security
http://hecker.org/mozilla/ssl-ui
https://blogs.msdn.microsoft.com/ie/2005/11/21/better-website-identification-and-extended-validation-certificates-in-ie7-and-other-browsers/

Perhaps you'd like to correct the misstatements, having been pointed to
contemporaneous statements from people actually there and involved in the
decisions, which I can hope you were simply unaware of?

Peter Bowen

unread,
Aug 14, 2019, 3:55:08 PM8/14/19
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote:

> On 14/08/2019 18:18, Peter Bowen wrote:
> > On thing I've found really useful in working on user experience is to
> > discuss things using problem & solution statements that show the before
> and
> > after. For example, "It used to take 10 minutes for the fire sprinklers
> to
> > activate after sensing excessive heat in our building. With the new
> > sprinkler heads we installed they will activate within 15 seconds of
> > detecting heat above 200ºC, which will enable fire suppression long
> before
> > it spreads."
> >
>
> It used to be easy for fraudsters to get an OV certificate with untrue
> company information from smaller CAs. By only displaying company
> information for more strictly checked EV certificates, it now becomes
> much more difficult for fraudsters to pretend to be someone else, making
> fewer users fall for such scams.
>
> Displaying an overly truncated form of the company information, combined
> with genuine high-trust companies (banks, credit card companies) often
> using obscure subsidiary names instead of their user trusted company
> names for their EV certs has greatly reduced this benefit.
>
> > If we assume for a minute that Firefox had no certificate information
> > anywhere in the UI (no subject info, no issuer info, no way to view
> chains,
> > etc), what user experience problem would you be solving by adding
> > information about certificates to the UI?
>
> This hasn't been the case since before Mozilla was founded.
>
> But lets assume we started from there, the benefit would be to tell
> users when they were dealing with the company they know from the
> physical world versus someone almost quite unlike them.
>
> Making this visible with as few (maybe 0) extra user actions increases
> the likelihood that users will spot the problem when there is one.
>

What is the problem being solved? You specify the benefit but I'm still
not clear why this info is needed in the first place.

Thanks,
Peter

Peter Gutmann

unread,
Aug 14, 2019, 8:49:07 PM8/14/19
to Jakob Bohm, Peter Bowen, mozilla-dev-s...@lists.mozilla.org
Peter Bowen via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>I have to admit that I'm a little confused by this whole discussion. While
>I've been involved with PKI for a while, I've never been clear on the
>problem(s) that need to be solved that drove the browser UIs and creation of
>EV certificates.

Oh, that's easy:

A few years ago certificates still cost several hundred dollars, but now
that the shifting baseline of certificate prices and quality has moved to
the point where you can get them for $9.95 (or even for nothing at all) the
big commercial CAs have had to reinvent themselves by defining a new
standard and convincing the market to go back to the prices paid in the good
old days.

This déjà-vu-all-over-again approach can be seen by examining Verisign’s
certificate practice statement (CPS), the document that governs its
certificate issuance. The security requirements in the EV-certificate 2008
CPS are (except for minor differences in the legalese used to express them)
practically identical to the requirements for Class 3 certificates listed in
Verisign’s version 1.0 CPS from 1996 [ ]. EV certificates simply roll back
the clock to the approach that had already failed the first time it was
tried in 1996, resetting the shifting baseline and charging 1996 prices as a
side-effect. There have even been proposals for a kind of sliding-window
approach to certificate value in which, as the inevitable race to the bottom
cheapens the effective value of established classes of certificates, they’re
regarded as less and less effective by the software that uses them (for
example browsers would no longer display a padlock for them), and the
sliding window advances to the next generation of certificates until
eventually the cycle repeats.

That was written about a decade ago. As recent events have shown, it was
remarkably accurate. The sliding window has just slid.

Peter.

Jakob Bohm

unread,
Aug 14, 2019, 8:49:44 PM8/14/19
to mozilla-dev-s...@lists.mozilla.org
Problem example: User wants to visit the website of the well-known high
street bank whose massive sign on the outside wall and letterhead in
actual paper documents is "Example Bank of Lalaland". User receives a
(fake) e-mail telling him to go to "example.net" (or just makes a
trivial typo) for their new online offerings, that mail is genuinely
from "notifi...@example.net", because the scammers actual registered
example.net (the real bank is example.com). User opens
https://example.net in the latest browser and
is told by the UI that they are safely (padlock) connected to
example.net. But not that this isn't the "Example Bank of Lalaland"
properly registered with "the companies registry of Lalaland" and
regulated by "the banking authority of Lalaland" and with an official
company address at "central square 2, capitalcity, Lalaland" (a well
known 19th century banking building currently containing the mahogany
board room and a regular branch office).

With EV as currently implemented they (don't if the wrong domain) get a
green color indicating this certificate was issued to someone with a
proven ID, the name actually verified by the national corporate registry
(responsible for uniqueness) and the Lalaland country code. All with
near 0 user effort.

With the proposed UI change they get nothing (just a default padlock)
and with a bit of effort that this certificate was EV validated for
"Example Bank Ltd" (but not if this is "Example Bank of Lalaland" or
"Example Bank of Enemy Country Full of Phishers"). Users have to dig
into technical dialogs to see that this EV certificate may have the
wrong "JurisdictionOfIncorporation" value. And there's nothing that
Example Bank of Lalaland or even the government of Lalaland can do to
stop this or even prosecute the phishers, because there is no legal
cooperation with that enemy country.


See also the original summary from 2007 by Gerv:
https://blog.gerv.net/2007/06/spot_the_dog/

Peter Gutmann

unread,
Aug 14, 2019, 9:03:55 PM8/14/19
to mozilla-dev-s...@lists.mozilla.org, Jakob Bohm
Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Problem example:
>[...]

You're explaining how it's supposed to work in theory, not in the real world.

We have a decade of real-world data showing that it doesn't work, that there's
no benefit from EV certificates apart from the one to CA's balance sheets. So
the browser vendors are doing the logical thing, responding to the real-world
data and no longer pretending that EV certs add any security value, both in
terms of protecting users and of keeping out the bad guys - see the attached
screen clip, in this case for EV code-signing certs for malware, but you can
buy web site EV certs just as readily.

Peter.

Daniel Marschall

unread,
Aug 15, 2019, 2:52:57 AM8/15/19
to mozilla-dev-s...@lists.mozilla.org
Please tell me if I understand this correctly...
Is it that DV and EV certificates now both show the same lock symbol?
That would be a great harm in my opinion. And I do not understand why you want this change.

I think EV is very important and I explain why.

Let's look at following hypothetical case: We have google.com, paypal.com as well as goog1e.com and paypa1.com . Notice the two number 1 (one) instead of a lower case L in the latter two domains. (lowecase "L" and "one" look perfectly equal in Times New Roman. And lowercase "L" looks perfectly equal to uppercase "i" in Arial.)

In old Firefox, I get a green bar if I visit google.com and paypal.com, telling me that this is a well-known company that got the EV certificate.
The other fake domains goog1e.com and paypa1.com only have DV certificates by Let's Encrypt.

In the newer Firefox, both domains, the real one and the fake one both get a lock symbol. And I need to click the lock to see if it is DV or EV.

Do I understand that correctly?

And in regards to the comparison of Peter Bowen: If we assume that an improvement is that a fire sprinkler does react faster and more accurate, then why it is an improvement that old Firefox shows something, and the new Firefox does not show something? Is that an enhancement? No, it's removing something from the UI.

Buschart, Rufus

unread,
Aug 15, 2019, 6:43:48 AM8/15/19
to mozilla-dev-s...@lists.mozilla.org
Dear Daniel!

> Please tell me if I understand this correctly...
> Is it that DV and EV certificates now both show the same lock symbol?
> That would be a great harm in my opinion. And I do not understand why you want this change.
>
> I think EV is very important and I explain why.
>
> Let's look at following hypothetical case: We have google.com, paypal.com as well as goog1e.com and paypa1.com . Notice the two
> number 1 (one) instead of a lower case L in the latter two domains. (lowecase "L" and "one" look perfectly equal in Times New Roman. And
> lowercase "L" looks perfectly equal to uppercase "i" in Arial.)
>
> In old Firefox, I get a green bar if I visit google.com and paypal.com, telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only have DV certificates by Let's Encrypt.
>
> In the newer Firefox, both domains, the real one and the fake one both get a lock symbol. And I need to click the lock to see if it is DV or EV.
>
> Do I understand that correctly?

Any CA that strictly follow BRGs 4.2.1 should not issue a certificate for paypa1.com or goog1e.com. Until recently this was also done by Let's Encrypt, but they stopped doing so in January 2019 - https://community.letsencrypt.org/t/let-s-encrypt-no-longer-checking-google-safe-browsing/82168. Maybe someone from the Let's Encrypt team can explain, how they are now fulfilling this requirement.

/Rufus

Kurt Roeckx

unread,
Aug 15, 2019, 7:30:46 AM8/15/19
to Daniel Marschall, mozilla-dev-s...@lists.mozilla.org
On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via dev-security-policy wrote:
> In old Firefox, I get a green bar if I visit google.com and paypal.com, telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only have DV certificates by Let's Encrypt.

The green bar does not indicate that it's a well-known company. It
means someone payed for an EV certificate. The green bar does not
in any way say it's more secure or indicate that you're talking to
some trustworthy company. It only gives you a false sense of
security.


Kurt

Doug Beattie

unread,
Aug 15, 2019, 8:46:53 AM8/15/19
to Peter Gutmann, mozilla-dev-s...@lists.mozilla.org
Peter,

Do you have any empirical data to backup the claims that there is no benefit
from EV certificates? From the reports I've seen, the percentage of
phishing and malware sites that use EV is drastically lower than DV (which
are used to protect the cesspool of websites).

Doug



-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Peter Gutmann via dev-security-policy
Sent: Wednesday, August 14, 2019 9:04 PM
To: mozilla-dev-s...@lists.mozilla.org; Jakob Bohm
<jb-mo...@wisemo.com>
Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
of the URL bar

Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

dean...@gmail.com

unread,
Aug 15, 2019, 10:40:39 AM8/15/19
to mozilla-dev-s...@lists.mozilla.org
That's a pretty disingenuous description of EV certificates. Whether they paid for it or not isn't the issue. It means that some entity applied for an EV certificate, the CA used the vetting methods described in the CA/B Forum EV guidelines (which were agreed to by CAs and browsers) to verify the domain, the company, the address, location, etc. Only after that is complete is an EV certificate issued. The CA was then audited against the work they did (in addition to assuring they meet physical, network and other audit requirements), annually.
I have to agree with Jakob, it's remarkable that Mozilla would make such a drastic change with only a 2 day announcement and no discussion.

Tom Ritter

unread,
Aug 15, 2019, 1:13:24 PM8/15/19
to Doug Beattie, Peter Gutmann, MozPol
On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Peter,
>
> Do you have any empirical data to backup the claims that there is no
> benefit
> from EV certificates? From the reports I've seen, the percentage of
> phishing and malware sites that use EV is drastically lower than DV (which
> are used to protect the cesspool of websites).
>

I don't doubt that at all. However see the first email in this thread
citing research showing that users don't notice the difference.

Doug Beattie

unread,
Aug 15, 2019, 1:59:32 PM8/15/19
to Tom Ritter, MozPol, Peter Gutmann
So far I see is a number of contrived test cases picking apart small components of EV, and no real data to back it up. Mostly academic or irrelevant research, imho. Here are a couple of links posted in this thread:



https://www.typewritten.net/writer/ev-phishing/: This post is intended for a technical audience interested in how an EV SSL certificate can be used as an effective phishing device <but no evidence this is a real world security concern>



https://stripe.ian.sh/: EV certificates with colliding entity names can be generated, but to date, I don’t know of any real attacks, just this academic exercise. And how much did it cost and how long did it Ian to get certificates to perform this experiment? Way more time and money that a phisher would invest.



https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md references a number of studies. But none of them indicated that EV was bad or misleading or was a detriment to security, and a number of the references weren’t even related to EV (including irrelevant research links to bolster their claims to the uninformed)



I haven’t been counting the number of pro and cons emails, but there are a significant number of organizations questioning the changes by Google and Mozilla. Mozilla and Google should reconsider their proposed changes.



Yes, I work for a CA that issues EV certificates, but if there was no value in them, then our customers would certainly not be paying extra for them. Shouldn’t the large enterprises that see a value in identity (as does GlobalSign) drive the need for ending EV certificates? With Google and Mozilla being prominent Lets Encrypt sponsors we know their intent is to drive business to them vs. any of the commercially respectable CAs. It’s actually counter productive to security to sponsor a CA that issues so many certificates to phishing and malware sites without any consequences. Is this to increase the value of their malware site detection services? Maybe..

* https://www.usenix.org/system/files/soups2019-drury.pdf
* https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf



Baffled…







From: Tom Ritter <t...@ritter.vg>
Sent: Thursday, August 15, 2019 1:13 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: Peter Gutmann <pgu...@cs.auckland.ac.nz>; MozPol <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

Eric Mill

unread,
Aug 15, 2019, 3:14:04 PM8/15/19
to Doug Beattie, Tom Ritter, MozPol, Peter Gutmann
On Thu, Aug 15, 2019 at 1:59 PM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> So far I see is a number of contrived test cases picking apart small
> components of EV, and no real data to back it up. Mostly academic or
> irrelevant research, imho.


(posting in my personal capacity)

I don't think it's accurate to characterize the research dismissively as
academic or irrelevant. I also want to point out up top that Safari
announced it was removing the EV indicator over a year ago, in June 2018.


> https://stripe.ian.sh/: EV certificates with colliding entity names can
> be generated, but to date, I don’t know of any real attacks, just this
> academic exercise. And how much did it cost and how long did it Ian to get
> certificates to perform this experiment? Way more time and money that a
> phisher would invest.
>

Ian states this directly in the post. It is a trivial amount of money and
time:

"One question may be how practical this attack is for a real attacker who
desires to phish someone. First, from incorporation to issuance of the EV
certificate, I spent less than an hour of my time and about $177. $100 of
this was to incorporate the company, and $77 was for the certificate. It
took about 48 hours from incorporation to the issuance of the certificate."


CAs should be careful about casually and dramatically overestimating the
roadblocks that EV certificates present to attackers.

Even if Ian's experiment took 10 times as long in practice, and cost $1000
over a fortnight, this is well within what we should generally expect
attackers to spend on an organized phishing attack. I have been on the
receiving end, as a website owner whose service was spoofed, of
sophisticated phishing attacks, and I've observed attackers who are willing
to spend substantially more than that for what is by all evidence a
lucrative and often successful class of attack.

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md
> references a number of studies. But none of them indicated that EV was bad
> or misleading or was a detriment to security, and a number of the
> references weren’t even related to EV (including irrelevant research links
> to bolster their claims to the uninformed)
>

The burden is not on the web browsers to prove that EV is detrimental to
security - the burden is on third parties to prove that EV is beneficial.
The fact that it's been around for a long time is not sufficient. I don't
see any evidence that any of the links or resources on that page are
designed to mislead uninformed readers.


I haven’t been counting the number of pro and cons emails, but there are a
> significant number of organizations questioning the changes by Google and
> Mozilla. Mozilla and Google should reconsider their proposed changes.
>

I don't observe a significant number of organizations questioning these
changes, in this thread or externally, other than CAs. Not that there
aren't any, but I'm not seeing a significant hue and cry in the broader
ecosystem.

I certainly can't speak for the US government, but I can say that when I
worked for the executive branch for a federal agency, I observed a strong
trend in adopting DV certificates (typically automated) throughout the
executive branch. One of the more relevant changes I observed agencies make
was the Department of Defense explicitly updating their internal policies
to remove a requirement to use EV certificates for public properties.
Multiple federal agencies gave internal guidance to widely adopt DV
certificates internally, and you can see a public example of that in the
official guidance accompanying the White House's HTTPS directive at
https://https.cio.gov/certificates/#what-kind-of-certificate-should-i-get-for-my-domain
-

“Domain Validation” (DV) certificates are usually less expensive and more
amenable to automation than “Extended Validation” (EV) certificates. EV
certificates generally result in the domain owner’s name appearing in the
browser URL bar visitors see. Ordinary DV certificates are completely
acceptable for government use.


Given that Safari already removed the EV indicator well over a year ago, I
expect the guidance will be updated so as not to mislead agencies that EV
will continue to generally show their organization's name in browsers.

You can certainly still find EV certificates on some federal agency
websites out there, but overall, the trajectory away from them has been
clear and accelerating for years.


Yes, I work for a CA that issues EV certificates, but if there was no value
> in them, then our customers would certainly not be paying extra for them.


This is definitely not a strong argument. Enterprises do all sorts of
things they believe may be valuable, based on gut feelings or on outdated
best practices.

For example, 5 years ago, it was still conventional wisdom to periodically
rotate user passwords. After years of empirical research demonstrating the
opposite, NIST finally updated its guidance to make clear that this is
detrimental to user security, and so now enterprises are (grudgingly, in
many cases) starting to remove password rotation requirements.

Someone could have argued to NIST during their password guidance update
that "if periodic password rotation had no security value, all of these
organizations wouldn't be doing it", but that would have been an
exceptionally weak argument that, if it were taken seriously, would have
only hindered a valuable effort to improve organizational and personal
security.



> Shouldn’t the large enterprises that see a value in identity (as does
> GlobalSign) drive the need for ending EV certificates?


The only population any of us -- including large enterprises -- should be
looking to serve are end users. If the evidence suggests that end users are
not being benefited by EV certificates, there's not a strong argument to
keep it (regardless of how plausible you think the potential use in
phishing attacks is). Enterprises don't have a right to force web browsers
to maintain a channel to display a name in a particular place because they
like how it makes them feel to see it there.



> With Google and Mozilla being prominent Lets Encrypt sponsors we know
> their intent is to drive business to them vs. any of the commercially
> respectable CAs. It’s actually counter productive to security to sponsor a
> CA that issues so many certificates to phishing and malware sites without
> any consequences.


Let's Encrypt is a non-profit, and a huge part of what Let's Encrypt,
Google, and Mozilla have all contributed to spreading is the underlying
standard automation protocol behind it (ACME), as well as the open source
CA behind it (Boulder). Because Let's Encrypt and its sponsors have created
ACME, it is now easier than ever for CAs to compete with Let's Encrypt, and
for customers of Let's Encrypt to avoid vendor lock-in. I am personally
aware of commercial CAs that have adopted ACME for issuance. I'm also aware
of US government agencies -- some very large enterprises -- that are
creating ACME-based, Boulder-based CAs and will benefit in the long run
from the ease of migrating away from Let's Encrypt to their own
independently operated PKI.

This is all to say that it's inaccurate and unconstructive to point to
Let's Encrypt sponsorship as evidence of nefarious or self-interested
intent, and certainly not as damaging to large enterprises. The work
undertaken by these organizations has resulted in more freedom for large
enterprise customers, healthier competition among certificate authorities,
and more security for end users across the internet.


> Is this to increase the value of their malware site detection services?
> Maybe..
>

For the record, I'm not even aware of a malware detection service that
Mozilla operates. I believe they rely on Google Safe Browsing, even for
their particularly privacy-conscious Firefox Focus app. [1]

[1] https://support.mozilla.org/en-US/kb/safe-browsing-firefox-focus


>
> * https://www.usenix.org/system/files/soups2019-drury.pdf
> *
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf
>
>
>
> Baffled…
>
>
>
>
>
>
>
> From: Tom Ritter <t...@ritter.vg>
> Sent: Thursday, August 15, 2019 1:13 PM
> To: Doug Beattie <doug.b...@globalsign.com>
> Cc: Peter Gutmann <pgu...@cs.auckland.ac.nz>; MozPol <
> mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
> of the URL bar
>
>
>
>
>
> On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:
> dev-secur...@lists.mozilla.org> > wrote:
>
> Peter,
>
> Do you have any empirical data to backup the claims that there is no
> benefit
> from EV certificates? From the reports I've seen, the percentage of
> phishing and malware sites that use EV is drastically lower than DV (which
> are used to protect the cesspool of websites).
>
>
>
> I don't doubt that at all. However see the first email in this thread
> citing research showing that users don't notice the difference.
>
>
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


--
Eric Mill
617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone>

Ronald Crane

unread,
Aug 15, 2019, 3:16:45 PM8/15/19
to MozPol
On 8/15/2019 10:58 AM, Doug Beattie via dev-security-policy wrote:
> So far I see is a number of contrived test cases picking apart small components of EV, and no real data to back it up.
I also would like to see more evidence of problems. However, I have to
object to the idea that
> Mostly academic...research, imho...
is of little value. This treads dangerously close to nihilism.
> https://stripe.ian.sh/: EV certificates with colliding entity names can be generated, but to date, I don’t know of any real attacks, just this academic exercise. And how much did it cost and how long did it Ian to get certificates to perform this experiment? Way more time and money that a phisher would invest.
I question that a phisher, who stands potentially to gain hundreds of
thousands or millions of dollars by phishing, e.g., the customers of a
major bank, would not, as this paper says, invest "48 hours from
incorporation to the issuance of the certificate" and "$177". This is a
trivial investment for a non-frivolous financial phisher, let alone,
say, a foreign government interested in phishing, say, a
voter-registration (or -- shudder! -- an e-voting) site.
> Yes, I work for a CA that issues EV certificates, but if there was no value in them, then our customers would certainly not be paying extra for them.
That your customers may perceive additional value in them doesn't mean
that they provide additional value to the general internet user. That
said, I lean toward Mozilla letting this debate settle out before hiding
EV support in release Firefox.

-R

James Burton

unread,
Aug 15, 2019, 3:17:32 PM8/15/19
to Ronald Crane, MozPol
My understanding of the days before EV was that the CAs themselves made up
the validation requirements for DV and because of this there was an uneven
validation requirements across the industry. EV was the first document
created to solve this and standardise validation requirements for a
certificate type. Moving forward the baseline requirements has standardise
validation requirements for the DV certificate type and therefore EV is no
allowed needed.

Regarding the phishing aspect of EV, users have no clue what EV is and they
are more interested in looking for the padlock and completing the
checkout process.

Eric Rescorla

unread,
Aug 15, 2019, 4:12:25 PM8/15/19
to Doug Beattie, Peter Gutmann, mozilla-dev-s...@lists.mozilla.org
I expect this is true, but it seems to me that if anything it is an
argument that EV doesn't provide security value, not the other way around:
DV certificates are much cheaper to obtain than EV, and so naturally if you
just need a certificate you're going to get DV. OTOH, if users actually
trusted EV more, it might be worthwhile for an attacker to get EV anyway.

-Ekr

Doug
>
>
>
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On
> Behalf Of Peter Gutmann via dev-security-policy
> Sent: Wednesday, August 14, 2019 9:04 PM
> To: mozilla-dev-s...@lists.mozilla.org; Jakob Bohm
> <jb-mo...@wisemo.com>
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
> of the URL bar
>
> Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org>
> writes:
>
> >Problem example:
> >[...]
>
> You're explaining how it's supposed to work in theory, not in the real
> world.
>
> We have a decade of real-world data showing that it doesn't work, that
> there's no benefit from EV certificates apart from the one to CA's balance
> sheets. So the browser vendors are doing the logical thing, responding to
> the real-world data and no longer pretending that EV certs add any security
> value, both in terms of protecting users and of keeping out the bad guys -
> see the attached screen clip, in this case for EV code-signing certs for
> malware, but you can buy web site EV certs just as readily.
>
> Peter.

Ian Carroll

unread,
Aug 15, 2019, 6:00:15 PM8/15/19
to mozilla-dev-s...@lists.mozilla.org
On Thursday, August 15, 2019 at 10:59:32 AM UTC-7, Doug Beattie wrote:
> So far I see is a number of contrived test cases picking apart small components of EV, and no real data to back it up. Mostly academic or irrelevant research, imho. Here are a couple of links posted in this thread:
>
>
>
> https://www.typewritten.net/writer/ev-phishing/: This post is intended for a technical audience interested in how an EV SSL certificate can be used as an effective phishing device <but no evidence this is a real world security concern>
>
>
>
> https://stripe.ian.sh/: EV certificates with colliding entity names can be generated, but to date, I don’t know of any real attacks, just this academic exercise. And how much did it cost and how long did it Ian to get certificates to perform this experiment? Way more time and money that a phisher would invest.

To be clear, I obtained this certificate during lunch while I was in high school, but I'm sure you read the post explaining the cost/time already. I hope we can agree our bar for security is higher than "a kid who got bored".

>
>
>
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md references a number of studies. But none of them indicated that EV was bad or misleading or was a detriment to security, and a number of the references weren’t even related to EV (including irrelevant research links to bolster their claims to the uninformed)
>
>
>
> I haven’t been counting the number of pro and cons emails, but there are a significant number of organizations questioning the changes by Google and Mozilla. Mozilla and Google should reconsider their proposed changes.
>
>
>
> Yes, I work for a CA that issues EV certificates, but if there was no value in them, then our customers would certainly not be paying extra for them. Shouldn’t the large enterprises that see a value in identity (as does GlobalSign) drive the need for ending EV certificates? With Google and Mozilla being prominent Lets Encrypt sponsors we know their intent is to drive business to them vs. any of the commercially respectable CAs. It’s actually counter productive to security to sponsor a CA that issues so many certificates to phishing and malware sites without any consequences. Is this to increase the value of their malware site detection services? Maybe..

It is not worth it to respond to this bizarre theory. Sponsors of Let's Encrypt obviously have nothing to gain from more people using it; it's not like they pay dividends! You can slander them all you want, but it's not going to make anyone respect your opinion in the future.

Eric Mill

unread,
Aug 15, 2019, 6:30:34 PM8/15/19
to Doug Beattie, Tom Ritter, MozPol, Peter Gutmann
I'm told my previous message to this thread was flagged as spam for some of
the recipients. But it did get posted to the Google Group, so for those who
didn't get my previous reply, here it is:

https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/tO3k5ua0AQAJ

On Thu, Aug 15, 2019 at 1:59 PM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> So far I see is a number of contrived test cases picking apart small
> components of EV, and no real data to back it up. Mostly academic or
> irrelevant research, imho. Here are a couple of links posted in this
> thread:
>
>
>
> https://www.typewritten.net/writer/ev-phishing/: This post is intended
> for a technical audience interested in how an EV SSL certificate can be
> used as an effective phishing device <but no evidence this is a real world
> security concern>
>
>
>
> https://stripe.ian.sh/: EV certificates with colliding entity names can
> be generated, but to date, I don’t know of any real attacks, just this
> academic exercise. And how much did it cost and how long did it Ian to get
> certificates to perform this experiment? Way more time and money that a
> phisher would invest.
>
>
>
>
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md
> references a number of studies. But none of them indicated that EV was bad
> or misleading or was a detriment to security, and a number of the
> references weren’t even related to EV (including irrelevant research links
> to bolster their claims to the uninformed)
>
>
>
> I haven’t been counting the number of pro and cons emails, but there are a
> significant number of organizations questioning the changes by Google and
> Mozilla. Mozilla and Google should reconsider their proposed changes.
>
>
>
> Yes, I work for a CA that issues EV certificates, but if there was no
> value in them, then our customers would certainly not be paying extra for
> them. Shouldn’t the large enterprises that see a value in identity (as
> does GlobalSign) drive the need for ending EV certificates? With Google
> and Mozilla being prominent Lets Encrypt sponsors we know their intent is
> to drive business to them vs. any of the commercially respectable CAs.
> It’s actually counter productive to security to sponsor a CA that issues so
> many certificates to phishing and malware sites without any consequences.
> Is this to increase the value of their malware site detection services?
> Maybe..
>
> * https://www.usenix.org/system/files/soups2019-drury.pdf
> *
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf
>
>
>
> Baffled…
>
>
>
>
>
>
>
> From: Tom Ritter <t...@ritter.vg>
> Sent: Thursday, August 15, 2019 1:13 PM
> To: Doug Beattie <doug.b...@globalsign.com>
> Cc: Peter Gutmann <pgu...@cs.auckland.ac.nz>; MozPol <
> mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
> of the URL bar
>
>
>
>
>
> On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:
> dev-secur...@lists.mozilla.org> > wrote:
>
> Peter,
>
> Do you have any empirical data to backup the claims that there is no
> benefit
> from EV certificates? From the reports I've seen, the percentage of
> phishing and malware sites that use EV is drastically lower than DV (which
> are used to protect the cesspool of websites).
>
>
>
> I don't doubt that at all. However see the first email in this thread
> citing research showing that users don't notice the difference.
>
>
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


Nick Lamb

unread,
Aug 15, 2019, 8:16:42 PM8/15/19
to dev-secur...@lists.mozilla.org, Eric Rescorla
On Thu, 15 Aug 2019 22:11:37 +0200
Eric Rescorla via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I expect this is true, but it seems to me that if anything it is an
> argument that EV doesn't provide security value, not the other way
> around: DV certificates are much cheaper to obtain than EV, and so
> naturally if you just need a certificate you're going to get DV.
> OTOH, if users actually trusted EV more, it might be worthwhile for
> an attacker to get EV anyway.

It is as ever simultaneously reassuring and annoying to see EKR wrote
what I was thinking but more succinctly and a few hours before I get
time to draft an email.

Further:

My interpretation is that a LOT of phishing sites in 2019 only
have DV certificates because that was the default. The crooks didn't
think "I need a certificate" they thought "I need a web site" and in
2019 a typical web site comes with a certificate - same as you don't
need to buy separate seatbelts for your car these days.

If we are looking to protect users from Phishing, we should promote
WebAuthn, not Extended Validation, because we know WebAuthn actually
protects users from phishing.

Nick.

Peter Gutmann

unread,
Aug 15, 2019, 10:03:09 PM8/15/19
to Doug Beattie, mozilla-dev-s...@lists.mozilla.org
Doug Beattie <doug.b...@globalsign.com> writes:

>Do you have any empirical data to backup the claims that there is no benefit
>from EV certificates?

Uhhh... I don't even know where to start. We have over ten years of data and
research publications on this, and the lack of benefit was explicitly cited by
Google and Mozilla as the reason for removing the EV bling... one example is
the most obvious statistic, maintained by the Anti-Phishing Working Group
(APWG), which show an essentially flat trend for phishing over the period of a
year in which EV certificates were phased in, indicating that they had no
effect whatsoever on phishing. There's endless other stats showing that the
trend towards security is negative, i.e. it's getting worse every year, here's
some five-year stats from a quick google:

https://www.thesslstore.com/blog/wp-content/uploads/2019/05/Phishing-by-Year.png

If EV certs had any effect at all on security we'd have seen a decrease in
phishing/increase in security.

There is one significant benefit from EV certificates, which I've already
pointed out, which is to the CAs selling them. So when I say "there's no
benefit" I mean "there's no benefit to end users", which is who the
certificates are putatively helping.

Peter.

Peter Gutmann

unread,
Aug 15, 2019, 10:41:44 PM8/15/19
to Doug Beattie, Tom Ritter, MozPol
Doug Beattie <doug.b...@globalsign.com> writes:

>So far I see is a number of contrived test cases picking apart small
>components of EV, and no real data to back it up.

See the phishing stats from any source you care to use. I've already
mentioned the APWG which I consider the premier source, and also linked to the
SSL Store blog which happened to be the first Google hit, but feel free to
take any source of stats you trust, and see if you can find any that show that
phishing decreased and/or security increased due to EV certs.

I could also reverse this and say: You claim that EV certs are useful. Produce
some stats showing this. We could agree on using the APWG as our source,
since they're a pretty authoritative.

In either case, we've got a good, decade-long, reliable, heavily-analysed data
source, it's up to the two sides to use it to support their case. I've
already made mine.

>Yes, I work for a CA that issues EV certificates, but if there was no value
>in them, then our customers would certainly not be paying extra for them.

Must remember that one for the quotes file :-).

In case you're wondering why I find it amusing, consider this variant:

Yes, I work for Monster Cable, but if there was no value in our cables then


our customers would certainly not be paying extra for them.

Peter.

林維聰(Robin.Lin)

unread,
Aug 15, 2019, 10:49:37 PM8/15/19
to Peter Gutmann, Doug Beattie, mozilla-dev-s...@lists.mozilla.org
I think that the Phishing eventscount should focus on number of phishing events per organization.
If the phishing event count was decreased after an organization start to use EV certificate, the EV certificate should have some effect to reduce the phishing event.

Thanks,
Robin Lin

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Peter Gutmann via dev-security-policy
> Sent: Friday, August 16, 2019 10:03 AM
> To: Doug Beattie <doug.b...@globalsign.com>;
> mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of the
> URL bar
>

Peter Gutmann

unread,
Aug 15, 2019, 11:05:49 PM8/15/19
to Eric Mill, Doug Beattie, Tom Ritter, MozPol
Eric Mill <er...@konklone.com> writes:

>CAs should be careful about casually and dramatically overestimating the
>roadblocks that EV certificates present to attackers.

See also the screenshot I posted earlier.  That was from a black-market web
site selling EV certificates to anyone with the stolen credit cards to pay for
them.  These are legit EV certs issued to legit companies, available off the
shelf for criminals to use.  For a little extra payment you can get ones with
high SmartShield scores so your malware is instantly trusted by the victim's
PC.

>The burden is not on the web browsers to prove that EV is detrimental to
>security - the burden is on third parties to prove that EV is beneficial.

Yup, as per my previous post.  We've got a vast amounts of data on this, if
there was a benefit to users then it shouldn't be hard to show that from the
data.

Peter.

Doug Beattie

unread,
Aug 16, 2019, 7:56:05 AM8/16/19
to Peter Gutmann, mozilla-dev-s...@lists.mozilla.org
Peter,

I'm not claiming that EV reduces phishing globally, just for those sites
that use them. Do you have a chart that breaks down phishing attacks by SSL
certificate type?

Here is some research that indicates EV sites have a reduced phishing
percentage, so customers accessing EV protected sites are safer:
https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf

Jonathan Rudenberg

unread,
Aug 16, 2019, 9:04:35 AM8/16/19
to Doug Beattie, Peter Gutmann, mozilla-dev-s...@lists.mozilla.org
On Fri, Aug 16, 2019, at 07:56, Doug Beattie via dev-security-policy wrote:
> Peter,
>
> I'm not claiming that EV reduces phishing globally, just for those sites
> that use them. Do you have a chart that breaks down phishing attacks by SSL
> certificate type?
>
> Here is some research that indicates EV sites have a reduced phishing
> percentage, so customers accessing EV protected sites are safer:
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf

Doug,

Can you point me to the specific research you're referring to? All I see in this presentation that's remotely relevant is a breakdown of the certificate types used on detected phishing sites across a couple months. If this data is correct, it doesn't seem to be useful information, and actually proves one of the points that is behind the removal of EV UI.

If EV is required for a successful phishing attack, then attackers will just get EV certificates. But all of the research that has been repeatedly brought up in this thread shows that users don't use the EV UI when making decisions about whether to trust a website, explaining why phishing sites don't use EV very much.

Additionally, the idea that sites that use EV experience less phishing seems deeply flawed. Banks are a huge target for phishing, and most of their websites have EV certificates.

An interesting and clear recent example of this is PayPal, which is obviously a very popular target for phishing. paypal.com technically has an EV certificate, but due to the certificate chain used since early 2018, the EV UI does not show up in the most popular browser (Chrome) on the most popular desktop operating system (Windows)[1]. Given the amount of phishing that PayPal experiences, it seems likely to me that they would have figured out how to fix this if they thought it was worth the effort. They haven't.

Jonathan

[1] https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/

Doug Beattie

unread,
Aug 16, 2019, 9:31:24 AM8/16/19
to Jonathan Rudenberg, Peter Gutmann, mozilla-dev-s...@lists.mozilla.org




From: Jonathan Rudenberg <jona...@titanous.com>
Sent: Friday, August 16, 2019 9:04 AM
To: Doug Beattie <doug.b...@globalsign.com>; Peter Gutmann
<pgu...@cs.auckland.ac.nz>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
of the URL bar



On Fri, Aug 16, 2019, at 07:56, Doug Beattie via dev-security-policy wrote:

Peter,



I'm not claiming that EV reduces phishing globally, just for those sites

that use them. Do you have a chart that breaks down phishing attacks by SSL

certificate type?



Here is some research that indicates EV sites have a reduced phishing

percentage, so customers accessing EV protected sites are safer:

https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf



Doug,



Can you point me to the specific research you're referring to? All I see in
this presentation that's remotely relevant is a breakdown of the certificate
types used on detected phishing sites across a couple months. If this data
is correct, it doesn't seem to be useful information, and actually proves
one of the points that is behind the removal of EV UI.



DB: The presentation identifies that people don't set up phishing sites
using EV certificates, and yes, this data only over the last 11 months or
so.



If EV is required for a successful phishing attack, then attackers will just
get EV certificates. But all of the research that has been repeatedly
brought up in this thread shows that users don't use the EV UI when making
decisions about whether to trust a website, explaining why phishing sites
don't use EV very much.



DB: One of the reasons that phishers don't get EV certificates is because
the vetting process requires several interactions and corporate repositories
which end up revealing more about their identity. This leaves a trail back
to the individual that set up the fake site which discourages the use of EV.
DV is completely anonymous and leaves very few traces.



Additionally, the idea that sites that use EV experience less phishing seems
deeply flawed. Banks are a huge target for phishing, and most of their
websites have EV certificates.



DB: Yes, that's true. I was saying that phishing sites don't use EV, not
that EV sites don't get phished.



An interesting and clear recent example of this is PayPal, which is
obviously a very popular target for phishing. paypal.com technically has an
EV certificate, but due to the certificate chain used since early 2018, the
EV UI does not show up in the most popular browser (Chrome) on the most
popular desktop operating system (Windows)[1]. Given the amount of phishing
that PayPal experiences, it seems likely to me that they would have figured
out how to fix this if they thought it was worth the effort. They haven't.



DB: Maybe they should get an EV certificate and help train the users to look
for that on their login page to reduce the chances that their customers are
phished?



Jonathan



[1]
https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validat
ion-fud/

Ben Laurie

unread,
Aug 16, 2019, 9:33:44 AM8/16/19
to Doug Beattie, Jonathan Rudenberg, Peter Gutmann, mozilla-dev-s...@lists.mozilla.org
On Fri, 16 Aug 2019 at 14:31, Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> DB: Yes, that's true. I was saying that phishing sites don't use EV, not
> that EV sites don't get phished

Surely this shows that EV is not needed to make phishing work, not that EV
reduces phishing?



--
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*

Doug Beattie

unread,
Aug 16, 2019, 9:37:55 AM8/16/19
to Ben Laurie, Jonathan Rudenberg, Peter Gutmann, mozilla-dev-s...@lists.mozilla.org




From: Ben Laurie <be...@google.com>
Sent: Friday, August 16, 2019 9:33 AM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: Jonathan Rudenberg <jona...@titanous.com>; Peter Gutmann
<pgu...@cs.auckland.ac.nz>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of
the URL bar



On Fri, 16 Aug 2019 at 14:31, Doug Beattie via dev-security-policy
<dev-secur...@lists.mozilla.org
<mailto:dev-secur...@lists.mozilla.org> > wrote:

DB: Yes, that's true. I was saying that phishing sites don't use EV, not
that EV sites don't get phished

Surely this shows that EV is not needed to make phishing work, not that EV
reduces phishing?



[DB] It should show that users are safer when visiting an EV secured site.



--

I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.



https://g.co/u58vjr https://g.co/adjusu

(Google internal)

Zu

unread,
Aug 16, 2019, 10:05:07 AM8/16/19
to Doug Beattie, Ben Laurie, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Peter Gutmann
Good afternoon all,

I would like to chime in with my two cents, if allowed:

1. Users do not notice the absence of a positive indicator. There is ample evidence, academic and otherwise. If users did notice the absence of a positive indicator, it follows that phishing without an EV certificate would be non-existent, as users would be noticing the lack of EV. Seeing the success of phishing indicates that users do not check for the absence of the indicator.

2. Further, if users did notice the lack of positive indicators, you can bet that phisher's would do everything in their power to display the positive indicator. They don't, because... it doesn't matter. Even if we assumed that displaying the positive indicator did matter:

3. Obtaining an EV certificate is as easy as spending ~$100 to incorporate and waiting a day or two, or visiting an underground marketplace. It's not exactly breaking into Fort Knox.

Following these points to the logical conclusion, I cannot see why anyone (other than those with a financial interest in the sale of EV certificates) would be arguing against this UI change.

Cheers,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 16 August 2019 13:37, Doug Beattie via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> From: Ben Lauri...@google.com
> Sent: Friday, August 16, 2019 9:33 AM
> To: Doug Beattie doug.b...@globalsign.com
> Cc: Jonathan Rudenberg jona...@titanous.com; Peter Gutmann
> pgu...@cs.auckland.ac.nz; mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of
> the URL bar
>
> On Fri, 16 Aug 2019 at 14:31, Doug Beattie via dev-security-policy
> <dev-secur...@lists.mozilla.org
> mailto:dev-secur...@lists.mozilla.org > wrote:
>
> DB: Yes, that's true. I was saying that phishing sites don't use EV, not
> that EV sites don't get phished
>
> Surely this shows that EV is not needed to make phishing work, not that EV
> reduces phishing?
>
> [DB] It should show that users are safer when visiting an EV secured site.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
> #VerifyAllTheThings.
>
> https://g.co/u58vjr https://g.co/adjusu
>
> (Google internal)
>

Nick Lamb

unread,
Aug 16, 2019, 11:36:24 AM8/16/19
to dev-secur...@lists.mozilla.org, Doug Beattie
On Fri, 16 Aug 2019 13:31:08 +0000
Doug Beattie via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> DB: One of the reasons that phishers don't get EV certificates is
> because the vetting process requires several interactions and
> corporate repositories which end up revealing more about their
> identity. This leaves a trail back to the individual that set up the
> fake site which discourages the use of EV. DV is completely anonymous
> and leaves very few traces.

It's really tangential to Mozilla's purpose but it's worth dispelling
this myth.

Nothing about your identity is revealed. Let's take the country I live
in as an example, it looks superficially as though you need to reveal a
lot of personal details to register a company in the United Kingdom.
Surely this is all backed up with the considerable power of the
government of a major world power, and so if I can track down which
company is behind a phishing site then the individuals responsible
won't be hard to find right?

Er, no. If you just lie on the paperwork nothing will happen. If
private citizens point out specifically that the paperwork for your
company is a tissue of lies, Companies House will reply to explain that
alas the government doesn't have sufficient resources to investigate or
do anything about it and so it's just too bad their records are largely
fictitious nonsense. Still they promise they _care_ about this, it's
a top priority, just not one that anything will be done about...

There has been exactly one prosecution for lying to Companies House in
the modern era. They had the money and pursued it through the courts
very enthusiastically on exactly that one occasion and no other. Guess
why? Because someone wrote up paperwork for a bogus company naming
famous politicians who'd done nothing to fix this for years. That was
bad publicity, and so the government threw resources at "fixing" the
problem, ie prosecuting the person who pointed out the corruption.

Read "Where there's Muck there's Brass Plates" for further examples of
how much worse than few fraudsters phishing for bank credentials the
rot in British companies already is:
https://www.private-eye.co.uk/special-reports/where-theres-muck


Nick.

teg...@gmail.com

unread,
Aug 16, 2019, 11:54:20 AM8/16/19
to mozilla-dev-s...@lists.mozilla.org
On Thursday, August 15, 2019 at 10:59:32 AM UTC-7, Doug Beattie wrote:
> Yes, I work for a CA that issues EV certificates, but if there was no value in them, then our customers would certainly not be paying extra for them. Shouldn’t the large enterprises that see a value in identity (as does GlobalSign) drive the need for ending EV certificates? With Google and Mozilla being prominent Lets Encrypt sponsors we know their intent is to drive business to them vs. any of the commercially respectable CAs. It’s actually counter productive to security to sponsor a CA that issues so many certificates to phishing and malware sites without any consequences. Is this to increase the value of their malware site detection services? Maybe..
>
> * https://www.usenix.org/system/files/soups2019-drury.pdf
> * https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf
>
>
>
> Baffled…


I'm baffled that anyone who has worked for a corporation could, in good faith, wonder how executives could be hoodwinked by "security" people telling them they need EV certificates, and then going to their low-level tech grunts and demanding implementation regardless of value. I have been involved in multiple such discussions, and it's always the same.

Leo Grove

unread,
Aug 16, 2019, 12:47:49 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org
>
> See also the screenshot I posted earlier.  That was from a black-market web
> site selling EV certificates to anyone with the stolen credit cards to pay for
> them.  These are legit EV certs issued to legit companies, available off the
> shelf for criminals to use.  For a little extra payment you can get ones with
> high SmartShield scores so your malware is instantly trusted by the victim's
> PC.
>

Peter,

Are you referring to EV Code Signing certificates? I agree that needs to be addressed in another forum, but this discussion in on EV SSL/TLS and their value (or lack thereof) in the browser UI. Browsers do not support EV Code Signing in the UI as far as I know.

It's been documented that EV Code Signing certificates are on the black market. Did you see the same thing for EV SSL/TLS?

Leo

t...@callan-consulting.com

unread,
Aug 16, 2019, 4:17:19 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org
My apologies for not weighing in earlier, but like many others I was surprised by this announcement and had to make time to craft this message around other pressing demands. The original announcement above that the EV UI would be removed in October cited authorities and articles that were in favor of what Mozilla wants to do. It would be useful to this community to understand and consider other relevant evidence and arguments that were not included there.

By way of background, until recently almost all phishing and malware was on unencrypted http sites. They received a neutral UI, and the bad guys didn’t have to spend time and money getting a certificate, even a DV certificate, that might leave traces as to their identity. Users were told (and remembered the advice) to “look for the lock symbol” for greater security.

Then a few things happened in close proximity: (1) Google incentivized all websites to move to encryption through the use of its “Not secure” warning, (2) Mozilla instituted a similar “Not Secure” warning, and (3) Let’s Encrypt began offering anonymous, automated DV certificates to everyone, including known phishing sites, in part through Platinum-level financial support from Mozilla and Google.

As a result, virtually all phishing has now moved to DV encrypted websites which receive the lock symbol in Firefox, which was predictable. In fact, the FBI just issued a warning to consumers not to trust the https or lock symbol in browsers anymore [1], as half or more of phishing sites now display the lock symbol. [2]

It’s unclear how Mozilla plans to ramp up protection for Firefox users. Browser phishing filters such as Google Safe Browsing are good, but not perfect. According to the most recent NSS labs report issued in October 2018, GSB offers only about 79% user protection at “zero hour”, gradually rising to 95% protection after 2 days. [3] However, most phishing sites are shut down by then anyway. If a browser phishing filter is the main defense provided to users by Firefox, this means thousands of users can be harmed before a site is flagged for phishing. Clearly Mozilla should be looking for other ways to protect them.

That’s where EV certificates can help. Data shows that websites with EV certificates have a very low incidence of phishing. New research from RWTH Aachen University presented at Usenix this week measured the incidence of phishing sites using certificates of various validation levels [4]. EV certificates made up 0.4% of the total population of phishing sites with certificates but 7% of the “benign” (non-phishing) sites. Compare that to OV, where 15% of phishing sites had that certificate type and 35% of benign sites had the same. And compare that again to Let’s Encrypt certificates, which made up 34% of certificates for phishing sites and only 17% for benign sites.

This research validates the results of an earlier study of 3,494 encrypted phishing sites in February 2019 [5]. In this study the distribution of encrypted phishing sites by certificate type was as follows:

EV 0 phishing sites (0%)
OV 145 phishing sites (4.15%)*
DV 3,349 phishing sites (95.85%)

*(These phishing OV certs were mostly multi-SANs certs requested by CDNs such as Cloudflare containing multiple URLs for websites whose content the Subject of the OV cert did not control. Perhaps such certificates should be DV rather than OV.)

Furthermore, research from Georgia Tech shows that EV sites have an exceedingly low incidence of association with malware and known bad actors [6].

These studies show that the presence of an EV certificate has a strong negative correlation with criminal activity intent on victimizing the site visitor. In plain terms, users are safer when they visit sites with EV certs. Now, how do we use that?

This is where the argument that “users don’t see the absence of positive indicators” misses the mark for several reasons.
1. The internet is in possession of a clear signal of a site’s safety for the end user. The fact that popular end-user software fails to take advantage of this signal is a shortcoming of that software, not the signal.
2. Users are not a single homogenous group, and they don’t all behave the same. Proof positive of that fact is that most of the people participating in this thread do, in fact, notice whether or not an EV indicator is there. They are not the only ones in the world. In the absence of compelling reasons to remove the indicator, providing this evidence to some users is superior to providing it to none.
3. User behavior also changes based on context. The site visitor who suffers from interface blindness when everything is going well may become hyper aware when something suspicious occurs. If nothing else, the presence of an EV cert gives the likes of law enforcement a clear path forward when pursuing perpetrators of online crime.
4. Positive security indicators do work in many other contexts where expectations are predictable. Let’s take an offline example we’re all familiar with, the seat belt. Most people I know are expecting the feel of a seat belt across their laps and shoulders when in a moving car, and without it we feel uncomfortable. That is a positive security indicator. The reason we miss it when it’s absent is because it is consistent, ubiquitous, obvious, and important to us. There is no reason why an identity security indicator cannot meet these same criteria. Unfortunately, the EV security indicator has suffered from inconsistency across browsers and changing presentation over time, and the industry as a whole has done a poor job of educating relying parties on what this identity information means. These disadvantages are all addressable, if companies like major browser and OS vendors treat doing so as a priority.

Mozilla’s most pressing need right now is to work with other browsers to develop common UI features across laptops and mobile devices and to engage with CAs in common user training to help users make good security decisions based on available identity information. Common UI standards have been extraordinarily successful: The automotive stop sign used to vary country by country and state by state before it became standardized. If stop signs were always different and users didn’t know what they meant (no user training), then some might argue “Users don’t use stop signs to make security decisions (stopping their cars), so let’s just remove all stop signs.” But that would be exactly the wrong thing to do, leaving users even less secure.

In the absence of such an effort, instead of removing the EV UI entirely, maybe Mozilla should consider other options for presenting this information, including the approach taken by Apple a year ago: Show users the URL for the site they are on, but make the URL and lock symbol green for sites with proven identity (secured by an EV cert) and black for all other sites (including all DV sites). Users would at least have a signal that additional identity information was available. Combined with some amount of user training, users would be better off in the aggregate than they would with the flat removal of any identity indicator at all.

Without any other identity indicator in Mozilla, users have nothing to go on but the URL and for some but not all phishing sites, an interstitial warning. But as Google security researchers have stated, “People have a really hard time understanding URLs. They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity.” [7]

I personally was among the group who put together the original EV specification. At that time we imagined that EV would be an ongoing, evolving standard that the community continued to make better. When I hear objections about EV being less than perfect, I cannot help but think of the adage about perfect being the enemy of good. EV is good. It’s really good, and the statistics indicate that. Let’s focus our energy on making it even better, not throwing it away and being left with nothing.

[1] https://www.ic3.gov/media/2019/190610.aspx;
https://www.infosecurity-magazine.com/news/fbi-dont-trust-https-or-padlock-on-1/
[2] https://krebsonsecurity.com/2018/11/half-of-all-phishing-sites-now-have-the-padlock/
[3] https://www.nsslabs.com/blog-posts/2019/3/8/nss-tests-phishing-block-rates-on-windows-chromebooks-platforms
[4] https://www.usenix.org/system/files/soups2019-drury.pdf
[5] https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf See slide 8 for the difference in incidence between EV and DV phishing sites.
[6] Understanding the Role of Extended Validation Certificates in Internet Abuse (Georgia Tech Research Paper) https://www.instantssl.com/uploads/resources/Updated-EVSSL.pdf; The probability that an EV SSL certificate is associated with a domain associated with malware or a known bad actor is 0.013%.
[7] https://www.wired.com/story/google-wants-to-kill-the-url/?verso=true

Paul van Brouwershaven

unread,
Aug 16, 2019, 5:22:11 PM8/16/19
to t...@callan-consulting.com, mozilla-dev-s...@lists.mozilla.org
Thanks Tim, well written and I completely agree!

In this thread Issues have been raised about that EV validation is not
perfect and that criminals can obtain an EV certificate (if they reveal
their identity). I also agree that the validation can be improved, but as
Tim stated, that doesn't mean its not useful today.

Take for example Troy Hunt, who has been feeding this whole discussion, he
wrote in his own comments that he trusts an website with an EV certificate
more than others.

Training users to make good security decisions based on available identity
information is something that would make a real difference.

I feel that browsers can have significant impact, if they would explain the
EV information when a user starts the browser for the first time and when
they attend the user on the presence of the organization name when they
haven't seen one recently for example. But don't get me wrong, this is not
only the responsibility of the browsers, also the CA's should take
responsibility and reserve a part of the revenue for user education.
> _______________________________________________

Kurt Roeckx

unread,
Aug 16, 2019, 5:27:37 PM8/16/19
to t...@callan-consulting.com, mozilla-dev-s...@lists.mozilla.org
On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
>
> By way of background, until recently almost all phishing and malware was on unencrypted http sites. They received a neutral UI, and the bad guys didn’t have to spend time and money getting a certificate, even a DV certificate, that might leave traces as to their identity. Users were told (and remembered the advice) to “look for the lock symbol” for greater security.
>
> Then a few things happened in close proximity: (1) Google incentivized all websites to move to encryption through the use of its “Not secure” warning, (2) Mozilla instituted a similar “Not Secure” warning, and (3) Let’s Encrypt began offering anonymous, automated DV certificates to everyone, including known phishing sites, in part through Platinum-level financial support from Mozilla and Google.
>
> As a result, virtually all phishing has now moved to DV encrypted websites which receive the lock symbol in Firefox, which was predictable. In fact, the FBI just issued a warning to consumers not to trust the https or lock symbol in browsers anymore [1], as half or more of phishing sites now display the lock symbol. [2]
>
> It’s unclear how Mozilla plans to ramp up protection for Firefox users. Browser phishing filters such as Google Safe Browsing are good, but not perfect. According to the most recent NSS labs report issued in October 2018, GSB offers only about 79% user protection at “zero hour”, gradually rising to 95% protection after 2 days. [3] However, most phishing sites are shut down by then anyway. If a browser phishing filter is the main defense provided to users by Firefox, this means thousands of users can be harmed before a site is flagged for phishing. Clearly Mozilla should be looking for other ways to protect them.
>
> That’s where EV certificates can help. Data shows that websites with EV certificates have a very low incidence of phishing. New research from RWTH Aachen University presented at Usenix this week measured the incidence of phishing sites using certificates of various validation levels [4]. EV certificates made up 0.4% of the total population of phishing sites with certificates but 7% of the “benign” (non-phishing) sites. Compare that to OV, where 15% of phishing sites had that certificate type and 35% of benign sites had the same. And compare that again to Let’s Encrypt certificates, which made up 34% of certificates for phishing sites and only 17% for benign sites.
>
> This research validates the results of an earlier study of 3,494 encrypted phishing sites in February 2019 [5]. In this study the distribution of encrypted phishing sites by certificate type was as follows:
>
> EV 0 phishing sites (0%)
> OV 145 phishing sites (4.15%)*
> DV 3,349 phishing sites (95.85%)
>
> *(These phishing OV certs were mostly multi-SANs certs requested by CDNs such as Cloudflare containing multiple URLs for websites whose content the Subject of the OV cert did not control. Perhaps such certificates should be DV rather than OV.)
>
> Furthermore, research from Georgia Tech shows that EV sites have an exceedingly low incidence of association with malware and known bad actors [6].
>
>
> These studies show that the presence of an EV certificate has a strong negative correlation with criminal activity intent on victimizing the site visitor. In plain terms, users are safer when they visit sites with EV certs. Now, how do we use that?

So they either don't have anything to do, just check some box, or need
to spend 1 minute to get a DV certs. And as your research shows,
DV certs are good enough to do phishing, they don't need EV certs,
so why would they bother?

But they you also say that 0.4% actually used an EV certificate.
My guess in that case is that they didn't actually bother to get
an EV ceritificate, but just hacked some website that just happens
to have an EV certificate.

I also think that 7% of the non-phising sites using EV
certificates doesn't make sense at all, and that's most likely a
sample bias.

> This is where the argument that “users don’t see the absence of positive indicators” misses the mark for several reasons.
> 1. The internet is in possession of a clear signal of a site’s safety for the end user. The fact that popular end-user software fails to take advantage of this signal is a shortcoming of that software, not the signal.

So here you turn a correlation into a causation.

> 3. User behavior also changes based on context. The site visitor who suffers from interface blindness when everything is going well may become hyper aware when something suspicious occurs. If nothing else, the presence of an EV cert gives the likes of law enforcement a clear path forward when pursuing perpetrators of online crime.

phishing sites don't expect everybody to be fooled. If 1 in 10000
is fooled, they have a very good day.

> 4. Positive security indicators do work in many other contexts where expectations are predictable. Let’s take an offline example we’re all familiar with, the seat belt. Most people I know are expecting the feel of a seat belt across their laps and shoulders when in a moving car, and without it we feel uncomfortable. That is a positive security indicator. The reason we miss it when it’s absent is because it is consistent, ubiquitous, obvious, and important to us. There is no reason why an identity security indicator cannot meet these same criteria. Unfortunately, the EV security indicator has suffered from inconsistency across browsers and changing presentation over time, and the industry as a whole has done a poor job of educating relying parties on what this identity information means. These disadvantages are all addressable, if companies like major browser and OS vendors treat doing so as a priority.

My day job involves seatbelts. I will always wear them when I can,
I know how important they are. But I also end up in situations where
it's not possible to wear them. And in most cases after 1 minute I
forget about it that I'm not wearing one.

But EV certificates aren't even *security* indicators. They only
indicate that you're talking (in a secure way) to a server that
has the private key of an EV certificate. But security is more
than just the communication. EV certificate also don't signal that
it's more trustworthy.

But as EV you point out, there might be correlations. There is
(currently) a higher chance that it's not a phishing site when
it has an EV certificate, but you also show that it's not a
guarantee.


Kurt

Daniel Marschall

unread,
Aug 16, 2019, 6:15:49 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org
I have a few more comments/annotations:

(1) Pro EV persons argue "Criminals have problems getting an EV certificate, so most of them are using only DV certificates".

Anti EV persons argue "Criminals just don't use EV certificates, because they know that end users don't look at the EV indicator anyway".

I assume, we do not know which of these two assumptions fits to the majority of criminals. So why should we make a decision (change of UI) based on such assumptions?

(2) I am a pro EV person, and I do not have any financial benefit from EV certificates. I do not own EV certificates, instead my own websites use Let's Encrypt DV certificates. But when I visit important pages like Google or PayPal, I do look at the EV indicator bar, because I know that these pages always have an EV certificate. If I would visit PayPal and only see a normal pad lock (DV), then I would instantly leave the page because I know that PayPal always has an EV certificate. So, at least for me, the UI change is very negative (except if you color the pad lock in a different color, that would be OK for me). We cannot say that all users don't care about the EV indicator. For some users like me, it is important.

(3) Also, I wanted to ask, if you want to remove the UI indicator, because you think that EV certificates give the feeling of false security, then please tell me: What is the alternative? Removing the UI bling without giving any alternative solution is just wrong in my opinion. Yes, there might be a tiny amount of phishing sites that use EV certificates, but the EV indicator bar is still better than just nothing. AntiPhishing filters are not a good alternative because they only protect when the harm is already done to some users.

Matthew Hardeman

unread,
Aug 16, 2019, 6:19:41 PM8/16/19
to Daniel Marschall, mozilla-dev-security-policy
Honestly the issues, as I see them, are twofold:

1. When I visit a site for the first time, how do I know I should expect
an EV certificate? I am conscientious about subsequent visits, especially
financial industry sites.

2. The browsers seem to have a bias toward the average user, that user
literally being less ...smart/aware... than half of all of users. EV is a
feature that can only benefit people who are vigilant and know what to look
for. It seems dismissive of the more capable users, but I suppose that's
their call.

James Burton

unread,
Aug 16, 2019, 6:56:39 PM8/16/19
to Matthew Hardeman, Daniel Marschall, mozilla-dev-security-policy
If one compares the first EV specification with the current EV
specification one will notice that the EV specification hasn't changed that
much during its lifetime. The issues presented during the last years though
research have been known about since the first adoption of the EV
specification. If CAs really cared about EV they would have tried and
improved it during the past 10+ years but nothing happened. If browsers
decided to keep EV what would change? Nothing at all.

There is no one point in discussing the removal of EV any further because
the EV specification had already died.

Corey Bonnell

unread,
Aug 16, 2019, 8:39:15 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org
> (2) I am a pro EV person, and I do not have any financial benefit from EV certificates. I do not own EV certificates, instead my own websites use Let's Encrypt DV certificates. But when I visit important pages like Google or PayPal, I do look at the EV indicator bar, because I know that these pages always have an EV certificate. If I would visit PayPal and only see a normal pad lock (DV), then I would instantly leave the page because I know that PayPal always has an EV certificate. So, at least for me, the UI change is very negative (except if you color the pad lock in a different color, that would be OK for me). We cannot say that all users don't care about the EV indicator. For some users like me, it is important.

I'd like to point out that Google does not use EV certificates. In fact, the only EV certificate that I could find containing a google.com SAN was the "test certificate" mis-issued by Symantec back in 2015: https://crt.sh/?id=9314698.

My goal is to not merely be pedantic by pointing this out, but rather I think it illustrates a valuable point: the effectiveness of the EV UI treatment is predicated on whether or not the user can memorize which websites always use EV certificates *and* no longer proceed with using the website if the EV treatment isn't shown. That's a huge cognitive overhead for everyday web browsing and one that very few (if any) users would be willing to do. If users do not make actionable decisions based on the presence/absence of the "green bar", then what purpose does it really serve?

Thanks,
Corey

Peter Gutmann

unread,
Aug 16, 2019, 9:01:59 PM8/16/19
to Doug Beattie, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
Doug Beattie <doug.b...@globalsign.com> writes:

>One of the reasons that phishers don’t get EV certificates is because the
>vetting process requires several interactions and corporate repositories
>which end up revealing more about their identity. This leaves a trail back
>to the individual that set up the fake site which discourages the use of EV.

Again, this is how it works in theory and in CA sales pitches (OK, that second
bit was redundant). Since you can buy EV certs off-the-shelf from underground
web sites, or get them directly yourself if you want to put in the effort, it
obviously doesn't work that way in practice.

In any case though that's just a distraction: Since phishing has been on the
increase year after year, the existence of EV certs is entirely irrelevant.
There's a great Dave Barry joke [0] where he explains how to threaten someone
with dynamite: You call them up, hold the burning dynamite fuse up to the
handset and say "You hear that? That's dynamite baby!".

EV certs are the same thing. "You see that? That's an EV cert baby!". It's
as effective a threat to phishing as Dave Barry's dynamite threat.

Peter.

[0] This joke has been credited to a number of sources, including Dave Barry.
It sounds like a Dave Barry to me.

Peter Gutmann

unread,
Aug 16, 2019, 9:09:09 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org, Leo Grove
Leo Grove via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Are you referring to EV Code Signing certificates? I agree that needs to be
>addressed in another forum, but this discussion in on EV SSL/TLS and their
>value (or lack thereof) in the browser UI. Browsers do not support EV Code
>Signing in the UI as far as I know.
>
>It's been documented that EV Code Signing certificates are on the black
>market. Did you see the same thing for EV SSL/TLS?

Yes, you can buy both, I used the code-signing EV one because I happened to
have a screenshot handy from a writeup I'm working on. In addition, EV code-
signing certs are much higher value, particularly when they come with
SmartScreen ratings, because they give you instant malware execution on a
billion plus systems, while EV web site certs are kinda meh. So EV code
signing is the holy grail, the hardest to get, and yet they're readily
available on the black market. EV web site certs are an afterthought in
comparison, "we also have those if you want 'em".

Peter.

Peter Gutmann

unread,
Aug 16, 2019, 9:15:25 PM8/16/19
to mozilla-dev-s...@lists.mozilla.org, Corey Bonnell
Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>the effectiveness of the EV UI treatment is predicated on whether or not the
>user can memorize which websites always use EV certificates *and* no longer
>proceed with using the website if the EV treatment isn't shown. That's a huge
>cognitive overhead for everyday web browsing

In any case things like Perspectives and Certificate Patrol already do this
for you, with no overhead for the user, and it's not dependent on whether the
cert is EV or not. They're great add-ons for detecting sudden cert changes.

Like EV certs though, they hav