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

[Wayne Thayer]

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]

> 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]

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]

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]

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]

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]

在 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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)]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

>
> 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]

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]

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]

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]

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]

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]

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]

> (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]

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]

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]

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 have no effect on phishing. They do very
effectively detect MITM, but for most users it's phishing that's the real
killer.

Peter.

[Leo Grove]

I don't know about other CAs, but at SSL.com we issue a very limited number of EV SSL certificates in comparison to other certificates so it's not a big revenue driver.

However, as a user I support EV SSL. I personally have never come across a scam site that displayed an EV SSL (I'm not saying they don't exist). Has anyone else come across a "scam site" displaying EV that's not part of an academic exercise?

An EV SSL only connects the site domain to its registered owner, nothing more. After that, I can decide whether to trust that company or if more research is warranted. At the end of the day, the user must make a decision based on the information they are given. This includes reviewing the EV SSL, domain name, site contents and third party reviews and listings. With the removal of EV from the browser UI, that's one less signal users can rely on.

For instance, my inbox receives increasingly sophisticated spam and phishing mailers that require me to do double and triple takes. This results in legitimate emails potentially being flagged as spam. One of the signals I use to verify linked sites within the emails is if they display EV certificates. I do not entirely rely on EV, but it helps to build a subconscious trust profile of that site along with the domain, content, site reviews and search listings. As a result, I've determined on a number of occasions that the emails were indeed authentic in part because of the EV. In this business, paranoia is survival.

Recently a neighbor asked me to verify a shoe site that he just purchased loafers from. Several red flags (ie Chanel header banner, unfamiliar domain name, etc) and no EV SSL prompted me to recommend he dispute the charge. Weeks later he confirmed it was indeed a scam site. Had the site displayed an EV SSL, I would have investigated more knowing the extra effort required to pass EV validation. But since no EV SSL appeared on the site, I didn't feel the need to waste any more time on the site.

I can't be the only person whose aunt, neighbor or spouse asks me to help verify a site. This tells me that they do not understand how to properly read the EV information, not that EV SSL is bad or ineffective.

I'm confounded why anyone would want less independently verified information on a site as opposed to more for fear EV doesn't perfectly suit their expectations. Well-known sites like google.com and amazon.com might not need EV as much as less well-known sites, but there are only a small number of these well-known sites.

In comparison, the vast majority of sites are lesser-known and could benefit from as many validation signals as possible. I would think a local hospital or credit union who are increasingly targeted by phishing scams might argue an EV certificate would be one of the tools to help combat these types of scams.

No single solution is perfect to eliminate online scams including EV SSL, but by removing the EV UI, the proverbial baby bath water comes to mind. I think the original intent of EV was and still remains noble. We should try to improve upon it, not discard it or relegate it to a virtually useless state.

Scammers are a wily bunch, and they will always find some success in gaming or circumventing any system where human trust is involved. Let's try to make if harder for them, not throw our hands in the air and give up. At a minimum, consider keeping a color coded lock that would not take up any additional browser real estate and would give users "in the know" the EV signal.

Otherwise, if the browsers have finalized their collective decisions on the matter, I do hope something better comes along that will benefit everyone. Treating all SSL/TLS certs as DV I think is a step backwards to 2007 when there was no EV, but we all knew something more than DV or OV was needed.

Leo

[Jakob Bohm]

Your legendary dislike for all things X.509 is showing. You are
constantly arguing that because they are not perfect, they are useless,
while ignoring any and all improvements since you original write ups.

You really should look at the long term agendas at work here and
reconsider what you may be inadvertently supporting.


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

[Peter Gutmann]

Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Your legendary dislike for all things X.509 is showing.

My dislike for persisting mindlessly with stuff we already know doesn't work
is showing (see in particular the quote typically misattributed to Einstein
about the definition of insanity), and given the rich target environment
that's available in the security field that's in no way limited to X.509.
Apart from that, you're quite correct.

It's not working.

It's obvious that it's not working.

It's been obvious for years that it's not working.

Time to try a new approach, rather than just repeating a new variant of what
we already know doesn't work all over again.

Peter.

[Jakob Bohm]

On 17/08/2019 00:56, James Burton wrote:
> 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.

Latest change was May 21, 2019. This added a way to include additional
government identifiers and very strict validation if that was a banking
identity.

The EV standards development has always been an adversarial thing with
relying party representatives (only browsers allowed to participate,
unfortunately) requiring stronger checks and CAs trying to minimize the
requirements imposed on them.

The alleged "issues presented during the last years through research"
are mostly red herrings.

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

This change doesn't just remove EV, it kills OV too. I have always
argued that the UI difference between EV and OV should be reduced or
removed, but removing the difference between EV and DV is so obviously
malicious it is indefensible.

>
> On Fri, Aug 16, 2019 at 11:19 PM Matthew Hardeman via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> 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.

A stronger, less confusing UI indicator of EV vs. DV (the important
distinction) would greatly reduce that problem. Instead there has been
an agenda to gradually fade the indication into invisibility, and this
is apparently the final blow.

An obvious non-malicious way forward would be:

1. Reject and revert this malicious change from Mozilla based browsers
and market this difference as a major benefit of Firefox over the 3
platform browsers (IE/Edge, Safari and Chrome). Minor browsers are
thus shown that there still is a real choice to be better too.

2. Restore the clear rule that the entire address bar will be in the
color of the certificate validation strength, (initially green for
EV, white for DV/none, Red for clearly invalid). Not just a partial
coloration.

3. Fix the indicator weaknesses (spoofable color favicon in indicator
area, not switching to the color of a weaker page element cert,
showing identity fields that are not the same for all page elements).

4. Use different color for OV vs. no cert/DV to reflect the actual
difference.

5. Display the information from OV certs like the same information in
EV certs, even if it doesn't qualify for EV color. For example
company name and country in OV color where those values pass all
checks except being EV.

6. Continue to push for stronger (but not excessive) validation of
certificate elements other than the domain name. For example there
should be meaningful validation that the certificate requester
controls the claimed street address, but having to send an man to
physically visit every business address every few years would be too
much for regular EV certs, but still appropriate for "high value/risk
identities" (similar to "high value/risk domains", but different
fields).

>>
>> On Fri, Aug 16, 2019 at 5:15 PM Daniel Marschall via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> 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.
>>>

Note: Google, as a major proponent of this change, has (almost?) no
website EV certs.

>>> (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.

[Matt Palmer]

On Fri, Aug 16, 2019 at 03:15:39PM -0700, Daniel Marschall via dev-security-policy wrote:
> (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.

This would be a stronger argument if any Google property had an EV certificate,
or if paypal.com had been displaying an EV treatment on the most commonly
used Browser/OS combo for the past year.

> 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'm sure a browser plugin could be developed to provide some sort of
indication that a certificate being presented was EV, and you could install
that if you were sufficiently interested.

- Matt

[Matt Palmer]

On Fri, Aug 16, 2019 at 10:03:53PM -0700, Leo Grove via dev-security-policy wrote:
> However, as a user I support EV SSL. I personally have never come across
> a scam site that displayed an EV SSL (I'm not saying they don't exist).
> Has anyone else come across a "scam site" displaying EV that's not part of
> an academic exercise?

Counter-question: why does that matter?

- Matt

[Matt Palmer]

On Thu, Aug 15, 2019 at 05:58:56PM +0000, Doug Beattie via dev-security-policy wrote:
> Shouldn’t the large enterprises that see a value in identity (as
> does GlobalSign) drive the need for ending EV certificates?

Can you point me to the in-progress discussion in the CA/B Forum lists
that is proposing to end EV certificates? From what I can see so far,
browser vendors aren't "ending" EV certificates, a couple of them are merely
modifying their UIs guided by relevant research into the efficacy (or lack
thereof) of the current UI.

- Matt

[Matt Palmer]

On Fri, Aug 16, 2019 at 01:37:40PM +0000, Doug Beattie via dev-security-policy 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.

When you have evidence of that, please feel free to share it. Everything
that has been presented so far doesn't *actually* show that, it merely shows
something else that people then furiously hand-wave into "see, security!".

- Matt

[Matt Palmer]

On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
> That’s where EV certificates can help. Data shows that websites with EV
> certificates have a very low incidence of phishing.

[...]

> 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%)

If you replace "EV" in the above with "WombleSecure(TM)(PatPend) security
seal", it is equally as true, and equally irrelevant. It's the old "tiger
repelling rock" spiel ("Do you see any tigers around? See, it works
great!") with a splash of X.509 for flavour.

It is not the hardest problem in science to design and execute an experiment
to demonstrate EV's efficacy. At the most basic level, it could be "here is
a site that was receiving X reports of users being phished per month, they
deployed an EV cert and their report rate went down to Y per month, here are
the confounding factors we considered and here's why they weren't the
cause". Increase the number of sites to improve power as needed.

That no EV-issuing CA has published the results of such an experiment, given
the large revenues it would protect, and the strong signalling that browsers
have been making over (at least) the last several years, the most plausible
explanation to me is that EV-issuing CAs *have* done the experiments, and
they didn't show anything, so in the finest traditions of
commercially-motivated science, they just buried it. The other option is
that the management EV-issuing CAs are just clueless, which is possible, but
not really any more comforting.

- Matt

[Paul van Brouwershaven]

On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, Aug 15, 2019 at 05:58:56PM +0000, Doug Beattie via
> dev-security-policy wrote:
> > Shouldn’t the large enterprises that see a value in identity (as
> > does GlobalSign) drive the need for ending EV certificates?
>
> Can you point me to the in-progress discussion in the CA/B Forum lists
> that is proposing to end EV certificates? From what I can see so far,
> browser vendors aren't "ending" EV certificates, a couple of them are
> merely
> modifying their UIs guided by relevant research into the efficacy (or lack
> thereof) of the current UI.
>

What evidence or research shows that the new location is providing better
protection for the end users?

[Leo Grove]

It matters because someone on this discussion claimed to be able to buy an EV SSL on the black market and used it as a supporting argument against EV. I'd honestly like to know if anyone has seen one in "in the wild" so to speak.

My write-up was from the perspective of a user so I'd like to know if I've been putting too much faith in EV SSL since there may be scam sites employing these pirated certificates.

Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but using an EV SSL in conjunction with a domain name and website with the true intent to dupe potential customers is another matter. I'm trying to get past the theoretical and get to real world instances.

Leo

[Ronald Crane]

On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:
> Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but using an EV SSL in conjunction with a domain name and website with the true intent to dupe potential customers is another matter. I'm trying to get past the theoretical and get to real world instances.

I don't understand the idea that the Stripe proof-of-concept is
"theoretical". We know that phishing is epidemic, and we also know that
phishers presently need -- at most -- a DV cert. The POC shows that --
should something cause phishers to need an EV cert -- they can also get
one of those quickly and inexpensively. But why would a phisher bother
with an EV cert if a DV cert works just as well?

-R

[Daniel Marschall]

Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:
>
> [...] From what I can see so far,

> browser vendors aren't "ending" EV certificates, a couple of them are merely
> modifying their UIs guided by relevant research into the efficacy (or lack
> thereof) of the current UI.
>
> - Matt

Matt, I don't understand this. Isn't removing the UI bling the same as "removing" EV from the browser? The UI difference is either so tiny or even not-existant, so I guess that EV will eventually ended by the Customers/CAs. I just looked at Opera and noticed that they don't have any UI difference at all, which means I have to open the X.509 certificate to see if it is EV or not.

[Matt Palmer]

On Sun, Aug 18, 2019 at 01:35:55PM -0700, Daniel Marschall via dev-security-policy wrote:
> Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:

> > [...] From what I can see so far,

> > browser vendors aren't "ending" EV certificates, a couple of them are merely
> > modifying their UIs guided by relevant research into the efficacy (or lack
> > thereof) of the current UI.
>

> Matt, I don't understand this. Isn't removing the UI bling the same as
> "removing" EV from the browser?

Yes, but removing EV from the browser isn't the same as ending EV
certificates, which is what was claimed in the message I responded to.

> I guess that EV will eventually ended by the Customers/CAs.

We'll have to leave it to the invisible hand of the market to sort that out.
If CAs cease issuing EV TLS/SSL certificates, it will presumably be because
customers are no longer buying them, and customers will cease buying them if
there is no perceived value in them, which is what CAs have repeatedly said
isn't the case. So CAs ceasing to issue EV TLS/SSL certificates will be a
confirmation that, in fact, EV TLS/SSL certificates had no value beyond the
UI "bling", as you call it, which the research overwhelmingly indicates is
of trivial value.

> I just looked at Opera and noticed that they don't have any UI difference
> at all, which means I have to open the X.509 certificate to see if it is
> EV or not.

So that's one more browser vendor that sees no value in "UI bling" for EV
certificates. It almost makes Firefox and Chrome look like the laggards in
this decision, rather than the harbingers of a new era.

- Matt

[Peter Gutmann]

Daniel Marschall via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>I just looked at Opera and noticed that they don't have any UI difference at
>all, which means I have to open the X.509 certificate to see if it is EV or
>not.

Does anyone know when Opera made the change? They had EV UI at one point, and
then there's this bug report:

https://forums.opera.com/topic/17923/ev-certificate-looks-like-ov

which blames the lack of EV UI on Chromium, so something inherited from
Chrome. It looks like it's then just a side-effect of the Chrome change and
allegedly "fixed in 44.0.2494.0", but Chrome 57 was from 2017, which means at
some point the change got reinstated.

Peter.

[Matt Palmer]

On Sun, Aug 18, 2019 at 09:14:52AM +0200, Paul van Brouwershaven wrote:
> On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, <
> dev-secur...@lists.mozilla.org> wrote:
> > On Thu, Aug 15, 2019 at 05:58:56PM +0000, Doug Beattie via
> > dev-security-policy wrote:
> > > Shouldn’t the large enterprises that see a value in identity (as
> > > does GlobalSign) drive the need for ending EV certificates?
> >
> > Can you point me to the in-progress discussion in the CA/B Forum lists

> > that is proposing to end EV certificates? From what I can see so far,

> > browser vendors aren't "ending" EV certificates, a couple of them are
> > merely
> > modifying their UIs guided by relevant research into the efficacy (or lack
> > thereof) of the current UI.
>

> What evidence or research shows that the new location is providing better
> protection for the end users?

I don't think it requires rigorous research to show that 0 >= 0.

- Matt

[scott...@gmail.com]

>
> What evidence or research shows that the new location is providing better
> protection for the end users?

What evidence or research shows that any location provides any protection for the end users?

[Tadahiko Ito]

(From my personal point of view)
I read Google’s paper[1].
For me, that paper’s result could be hypothesized like “some people do care about some information, which is written in EV but not in DV”.

That is…
(A) If you click EV indicator, you will able to get more information about identity (compare to DV).
(B) If you click page info without EV indicator, you usually only see DV cert’s identity information, which does not say much. (number of OV is far less than number of DV).

Expected amount of information, from action (A) and (B) is very different, and expected information from (B) is small.
So, even if there were someone who is aware of physical identity, He just do A) for best effort.

#for me, it sounds more reasonable than “large size of the EV indicator draws accidental clicks” (3.2.2 of [1]).

According to above thought, I feel like browser should (at least) differentiates
-DV AND
-OV or EV.
Otherwise, people who do care about information on OV or EV would become tired of clicking page info of DV.
#Do we just need identity on cyber space? I do not think many people would agree that.

[1] The Web’s Identity Crisis:Understanding the Effectiveness of Website Identity Indicators, https://storage.googleapis.com/pub-tools-public-publication-data/pdf/400599205ab5a1c9efa03e2a7c127eb8200bf288.pdf

[kirkhal...@gmail.com]

On Monday, August 12, 2019 at 2:31:22 PM UTC-4, Wayne Thayer 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.
>
> 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

Thanks to Tim Callan for making the case for keeping and even improving the EV UI in Firefox. I want to add a few more points to this interesting discussion.

Some have responded there is no research saying EV sites have significantly less phishing (and are therefore safer) than DV sites – Tim has listed two studies that say exactly that, and I’m not aware of any studies that say the opposite. I can tell you that anti-phishing services and browser phishing filters have also have concluded that EV sites are very unlikely to be phishing sites and so are safer for users.

Some opponents of the EV UI say it should go away because users don’t understand or know how to evaluate the specific organization information that’s displayed. That’s true to a point – but an improved EV UI for Firefox could follow Apple’s example by showing a binary “identity/no identity” UI that would be easy for users to understand – green lock symbol and URL for identity (EV), black for no identity (DV). If users want to see the specific organization information for the identity sites, it can be displayed with one click on the green lock symbol. With a little user training (such as a pop-up for a few months explaining what the green UI means), users could understand – after all, users still remember “look for the lock symbol” for user security.

Remember that the need for knowledge of a website’s identity is not homogenous across users and uses. For instance, users will have different needs to scrutinize identity information at different times. Let’s look at currency, for example. Currency contains many marks to validate its legitimacy such as watermarks, holograms, and the like. The same person may treat currency differently based on context. The same person might take cash out of the ATM machine with little close scrutiny but then look closely at the money received from a scalper at a sporting event or concert. In the first case, the context is considered to be low risk, and in the second it’s considered to be high risk. The security indicators are always there, so the relying party can take advantage of them when they’re warranted.

Likewise, some users have greater need for this knowledge. In another offline example, travelers don’t actually scrutinize the names of fellow passengers who board their airplane – but their security is greatly increased by the fact that the airlines and TSA *do* scrutinize fellow travelers for them, remember the passenger names, and check the names against lists of known terrorists before letting them board a plane.

That’s proactive security – checking for potential threats before letting a passenger get on an airplane. In contrast, just relying on a browser filter to protect users against phishing is like letting people get on the plane anonymously and even take off, but promising to blacklist any passenger from future flights who sneaks on with a weapon and attacks the other passengers.

That approach isn’t very effective – first, the bad guy has already harmed some passengers by the time of the blacklist, and second, if passengers can continue to board airplanes anonymously then any blacklisted passenger from an earlier flight can just get on another plane anonymously and repeat the exploit (just as anonymous phishers do repeatedly by constantly setting up new phishing websites which take time to be flagged by browser filters after the fact). Rewarding identity websites with a distinct EV UI is one way of providing user security proactively.

Instead of removing the EV UI entirely on the basis that users don’t understand the UI and don’t make security decisions based on the UI, maybe Mozilla should just simplify the EV UI and match what Apple did a year ago – show users the URL for the site they are at, but make the URL and lock symbol green for sites with identity (secured by an EV cert) and black for all other sites (including all DV sites). If users click on a green lock symbol, they can then see the EV data if they want to. And then Mozilla could do normal user training to tell them they are at safer sites when they see the green lock symbol and URL. (User training can be very simple but effective – many users still remember “look for the lock symbol” from the days when phishing used only http).

Finally, some on this list have said that if user trust in EV sites increases, then phishers will just start getting EV certificates. That’s possible, but remember one thing – once a phisher with an EV cert uses it for an exploit, the issuer will likely revoke the cert and add both the organization’s *name* and its phishing domains to its flag list – and the organization (a specific corporation identified by name, state of incorporation, and serial number) will never be able to get another EV cert from that CA, not even if the phisher changes to a different domain.

That means an EV phisher will likely get one use out of each corporation it forms to get the cert, and then will have to form another corporation to get another EV cert, and so forth. And CAs are currently setting up a common EV flag list so a corporation found to intentionally engaged in EV phishing probably won’t be able to get an EV certificate from another CA either. That’s probably one reason why phishers don’t use EV certs today – it’s too expensive and time consuming if you can only use your corporation’s EV cert in one phishing campaign (and then your corporation can never get another EV cert because of its past record).

Likewise, reports of EV certs being offered on the dark web are actually fairly humorous – it means scammers are scamming other scammers. Any phisher who buys an EV cert on the dark web can likely use it only once, and then the EV cert will be revoked and the phisher will be unable to get another EV cert for the same corporation – a pretty poor investment for the phisher, but maybe a good deal for the scammer who sells the EV cert on the dark web.

Today there’s a huge wave toward protecting consumer privacy – in Congress, with the GDPR, etc. – but how can we protect user privacy on the web without establishing the identity of the websites that are asking for consumer passwords and credit card numbers? EV certificates provides this information and can be very useful for consumers to determine this identity.

To close - browsers love data, and Mozilla has a lot of really smart engineers. That’s why I hope Mozilla will come up with innovative ways to use EV data, and not just drop it.

[Ronald Crane]

On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> I can tell you that anti-phishing services and browser phishing filters have also have concluded that EV sites are very unlikely to be phishing sites and so are safer for users.

Whatever the merits of EV (and perhaps there are some -- I'm not
convinced either way) this data is negligible evidence of them. A DV
cert is sufficient for phishing, so there's no reason for a phisher to
obtain an EV cert, hence very few phishing sites use them, hence EV
sites are (at present) mostly not phishing sites.

-R

[Leo Grove]

So you agree it's safe to assume with high probability that when I come across a site displaying an EV SSL, it's not a phishing site. I think that is one of the purposes of EV.

Or should we remove the EV bling because phishing sites prefer to use DV?

[Tom Ritter]

On Fri, 23 Aug 2019 at 05:00, Leo Grove via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote:

> So you agree it's safe to assume with high probability that when I come across a site displaying an EV SSL, it's not a phishing site. I think that is one of the purposes of EV.
>
> Or should we remove the EV bling because phishing sites prefer to use DV?

Correlation does not imply causation.

There are studies that show phishing sites tend not to be EV - yes.
That's a correlation.

If we studied phishing sites and domain name registration fees I'm
sure we'd find a correlation there too - I'd bet the .cfd TLD (which
apparently costs $16K to register) has a low incident of pishing as
well.

There are also studies that indicate users don't pay attention to the
(positive) security indicators. To phish users, it's unnecessary to
get an EV indicator vs a DV indicator. The simpler explanation for the
correlation is that EV is more expensive (both in direct cost, and in
effort to get misleading documents), so why would you pay for
something you don't need?

-tom

[Ronald Crane]

On 8/23/2019 6:41 AM, Tom Ritter via dev-security-policy wrote:
> On Fri, 23 Aug 2019 at 05:00, Leo Grove via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>> On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote:

>> So you agree it's safe to assume with high probability that when I come across a site displaying an EV SSL, it's not a phishing site. I think that is one of the purposes of EV.
>>
>> Or should we remove the EV bling because phishing sites prefer to use DV?
> Correlation does not imply causation.
>
> There are studies that show phishing sites tend not to be EV - yes.
> That's a correlation.
>
> If we studied phishing sites and domain name registration fees I'm
> sure we'd find a correlation there too - I'd bet the .cfd TLD (which
> apparently costs $16K to register) has a low incident of pishing as
> well.

I agree. Also, we really should be interested in what proportion of
legitimate EV sites are being impersonated, versus what proportion of
legitimate OV/DV sites are being impersonated. We also should be
interested in what happens when a legitimate site moves from OV/DV to
EV, or vice versa. Those stats would tell us something about EV's
effectiveness.
> ...To phish users, it's unnecessary to

> get an EV indicator vs a DV indicator. The simpler explanation for the
> correlation is that EV is more expensive (both in direct cost, and in
> effort to get misleading documents), so why would you pay for
> something you don't need?

Yep.

-R

[sslcor...@gmail.com]

>
> Correlation does not imply causation.
>
> There are studies that show phishing sites tend not to be EV - yes.
> That's a correlation.
>
> If we studied phishing sites and domain name registration fees I'm
> sure we'd find a correlation there too - I'd bet the .cfd TLD (which
> apparently costs $16K to register) has a low incident of pishing as
> well.
>
> There are also studies that indicate users don't pay attention to the
> (positive) security indicators. To phish users, it's unnecessary to
> get an EV indicator vs a DV indicator. The simpler explanation for the
> correlation is that EV is more expensive (both in direct cost, and in
> effort to get misleading documents), so why would you pay for
> something you don't need?
>
> -tom

I find this to a bit of a false equivalency.

Put another way, if EV was just as easy to obtain (in terms of cost and effort) as DV, everything else being equal, would phishing scammers still prefer DV over EV? Could the same be said about .cfd vs .com or .io?

My guess is that phishing sites would have more success, however incremental, (especially on high value sites such as banking) displaying EV UI, and the opposite would happen on a .cfd domain. In fact, one of the arguments against EV was that it gave a false sense of security to would-be victims. If I'm a scammer, that's what I want for my phishing site.

It does come down to cost vs benefit in the world of phishing economics. The incremental boost of an EV indicator is just not worth the expense in comparison with DV to most scammers. Now that the EV UI is going away, this is one less concern they will need to bother with. I don't think they're sad about this.

So I do see causation to low adoption of EV on phishing sites. But since DV is good enough for most run-of-the-mill scam sites, that's the common path.

[Daniel Marschall]

Can you proove that your assumption "very few phishing sites use EV (only) because DV is sufficient" is correct? I do think the truth is "very few phishing sites use EV, because EV is hard to get".

I do not think EV certificates are easy to get. The black market stories are probably more about code signing certificates, I guess. And even if you would find an EV SSL certificate on the black market, then it would be revoked as soon as it is used, and that organization will never get an EV certificate again. So the harm that black market certificates (if there are any at all...) is very small!

[Ronald Crane]

On 8/23/2019 3:53 PM, Daniel Marschall via dev-security-policy wrote:
> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:

> Can you proove that your assumption "very few phishing sites use EV (only) because DV is sufficient" is correct? I do think the truth is "very few phishing sites use EV, because EV is hard to get".

Well, I can't "prove" the assertion, but I can provide some evidence for
it. For example, Russia's GRU phished (Hillary Clinton's campaign
manager) John Podesta in 2016 using the URL-shortening service bit.ly.
[1] Since such services are widely used for legitimate links, most
people click on them as a matter of course, except for some denizens of
security forums such as this one. In any case, the link forwarded him to
an GRU site, into which he entered his Gmail credentials, and the rest
is history. I don't know whether the GRU site used an EV cert, but I am
unaware of any evidence for that idea.

Someone earlier in this thread cited a stat that the vast majority of
phishing sites that use certs use DV certs. According an (apparently
CA-sponsored) study from 2017 [2], only about 12% of phishing sites even
bother to use SSL. Of those, basically all use DV certs (Id. at p.2-3).
This data implies that most users who can be phished can be phished
without even using SSL, and most of the remainder can be phished using a
DV cert.

Now *maybe* (1) if EV certs were widely used, and (2) verification was
uniformly-strong, and (3) browser publishers really tried to train
users, and (4) legitimate sites stopped using URL-shortening services
and multiple domains, and (5) we solved the Stripe POC issue (multiple
domains presented as owned by a company with a name similar to the
desired one, but actually registered to a different entity in a
different jurisdiction), *then* EV would significantly improve users'
safety. Maybe.

-R

[1]
https://www.cbsnews.com/news/the-phishing-email-that-hacked-the-account-of-john-podesta/
. This article claims that the GRU successfully used the same trick on
(Former U.S. Secretary of State) Colin Powell and the Democratic
National Committee.

[2]
https://casecurity.org/wp-content/uploads/2017/09/Incidence-of-Phishing-Among-DV-OV-and-EV-Websites-9-13-2017-short-ve....pdf

>
> I do not think EV certificates are easy to get. The black market stories are probably more about code signing certificates, I guess. And even if you would find an EV SSL certificate on the black market, then it would be revoked as soon as it is used, and that organization will never get an EV certificate again. So the harm that black market certificates (if there are any at all...) is very small!

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

[Peter Bowen]

On Thu, Aug 22, 2019 at 1:44 PM kirkhalloregon--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Some have responded there is no research saying EV sites have
> significantly less phishing (and are therefore safer) than DV sites – Tim
> has listed two studies that say exactly that, and I’m not aware of any

> studies that say the opposite. I can tell you that anti-phishing services

> and browser phishing filters have also have concluded that EV sites are
> very unlikely to be phishing sites and so are safer for users.
>

> Some opponents of the EV UI say it should go away because users don’t
> understand or know how to evaluate the specific organization information
> that’s displayed. That’s true to a point – but an improved EV UI for
> Firefox could follow Apple’s example by showing a binary “identity/no
> identity” UI that would be easy for users to understand – green lock symbol
> and URL for identity (EV), black for no identity (DV). If users want to
> see the specific organization information for the identity sites, it can be
> displayed with one click on the green lock symbol.
>

> users will have different needs to scrutinize identity information at
> different times. Let’s look at currency, for example. Currency contains
> many marks to validate its legitimacy such as watermarks, holograms, and
> the like. The same person may treat currency differently based on

> context. The same person might take cash out of the ATM with little close

> scrutiny but then look closely at the money received from a scalper at a
> sporting event or concert. In the first case, the context is considered to
> be low risk, and in the second it’s considered to be high risk. The
> security indicators are always there, so the relying party can take
> advantage of them when they’re warranted.

> To close - browsers love data, and Mozilla has a lot of really smart
> engineers. That’s why I hope Mozilla will come up with innovative ways to
> use EV data, and not just drop it.
>

Kirk,

I think you hit the nail on the head here. One of the big advantages of
the PKI model used in the public Internet is that certificates are
independent of browsers. Different systems can use information contained
in the same certificate in different ways. The validated information is
present in the certificate regardless of the browser UI. Many browser
users have plugins installed to help detect malicious websites and software
downloads (frequently as part of an overall Internet security suite along
with anti-virus and anti-malware scanners). These Internet security tools
can use the EV data to help implement user controllable policies completely
independent of the core browser UI.

Additionally, many people and organizations have filtering proxies that can
do some level of introspection. My home router can do network filtering
and I know large enterprise firewalls do the same. In TLS 1.2, they can
review the certificate and terminate the connection if it doesn't meet the
policies of the proxy owner. This is an ideal place to check EV and does
not rely upon the end user remembering to check if the lock is black or
green.

There are also opportunities for browsers here. I have to admit I
primarily use Google Chrome, rather than Firefox, so my observations may be
a little tainted, but I see various places where signals far more valuable
than the green lock could be implemented. Consider that most browsers
recognize credit card entry fields -- wouldn't it be great if clicking on
one on an EV site showed a little drop down under the input box that said
"[CA name here] has certified that [EV info here] is receiving your credit
card information"?

I don't see the currently proposed change in the Firefox UI as having a
notable impact on the future of EV certificates.

Thanks,
Peter

[Tom Ritter]

On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:

> Can you proove that your assumption "very few phishing sites use EV (only) because DV is sufficient" is correct?

As before, the first email in the thread references the studies performed.

"By dividing these users into three groups, our controlled study
measured both the effect of extended validation certificates that
appear only at legitimate sites and the effect of reading a help file
about security features in Internet Explorer 7. Across all groups, we
found that picture-in-picture attacks showing a fake browser window
were as effective as the best other phishing technique, the homograph
attack. Extended validation did not help users identify either
attack."

https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf

"Our results showed that the identity indicators used in the
unmodified FF3browser did not influence decision-making for the
participants in our study interms of user trust in a web site. These
new identity indicators were ineffectivebecause none of the
participants even noticed their existence."

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf

DV is sufficient. Why pay for something you don't need?

-tom

[Jernej Simončič]

On Fri, 23 Aug 2019 15:53:21 -0700 (PDT), Daniel Marschall wrote:

> Can you proove that your assumption "very few phishing sites use EV (only) because DV is sufficient" is correct? I do think the truth is "very few phishing sites use EV, because EV is hard to get".

Before browsers started showing dire warnings on non-secure pages,
basically no phishing site bothered with SSL at all, since their target
audience simply didn't notice anything wrong.

--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

[Josef Schneider]

The important question is can they get this without making them easily traceable?
Sure I can register a company and get an EV certificate for that company. But can I do this completely anonymous like getting a DV cert?

How long do you think would it have taken for the police to come and get Ian Carroll if he'd actually committed fraud?

Nobody is arguing that EV certificates are perfect and everything is good if you use them. But they do raise the bar for criminals. And in my opinion, significantly.

What I propose is for mozilla to not say "Fuck it, it's not working, just remove it!" but instead try to focus on finding a better UX solution to the problem that end users are not aware if a site that should have an EV certificate is not presenting one.

- Josef

[Wayne Thayer]

On Mon, Aug 26, 2019 at 5:39 AM Josef Schneider via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:

> The important question is can they get this without making them easily
> traceable?
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?
>
> How long do you think would it have taken for the police to come and get
> Ian Carroll if he'd actually committed fraud?
>
> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them. But they do raise the bar for criminals. And in my
> opinion, significantly.
>
> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to the
> problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.
>
>

The counter-argument is that not all problems can be solved with UX, and
getting browser users to recognize and respond to the lack of an EV
indicator is in that class of unsolvable problems.

[Ronald Crane]

On 8/26/2019 5:39 AM, Josef Schneider via dev-security-policy wrote:
> Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:

> The important question is can they get this without making them easily traceable?
> Sure I can register a company and get an EV certificate for that company. But can I do this completely anonymous like getting a DV cert?
>
> How long do you think would it have taken for the police to come and get Ian Carroll if he'd actually committed fraud?

Probably years, if ever, particularly if he lived in a subpoena-haven
like Russia. My impression (as a U.S. citizen) is that U.S. police don't
take online crimes seriously, and neither does the federal government.
This idea is supported by the enormous amount of phishing and other
online frauds in the U.S. My email client flags several new
phishes/frauds each day. True, there has been a bit of action about the
online crimes that subverted U.S. elections in 2016, but that's an
unusual exception to the rule. Russia is, of course, refusing to
extradite the people that Sp. Counsel Mueller indicted.

> ...What I propose is for mozilla to not say "Fuck it, it's not working, just remove it!" but instead try to focus on finding a better UX solution to the problem that end users are not aware if a site that should have an EV certificate is not presenting one.

I think this is a reasonable idea, particularly the last clause. I am
not against EV, but neither am I convinced of its usefulness.

-R

[Jakob Bohm]

On 24/08/2019 05:55, Tom Ritter wrote:
> On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>>
>> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
>>> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
>>>
>>> Whatever the merits of EV (and perhaps there are some -- I'm not
>>> convinced either way) this data is negligible evidence of them. A DV
>>> cert is sufficient for phishing, so there's no reason for a phisher to
>>> obtain an EV cert, hence very few phishing sites use them, hence EV
>>> sites are (at present) mostly not phishing sites.
>>
>> Can you proove that your assumption "very few phishing sites use EV (only) because DV is sufficient" is correct?
>
> As before, the first email in the thread references the studies performed.

The (obviously outdated) studies quoted below were NOT referenced by the
first message in this thread. The first message only referenced two
highly unpersuasive demonstrations of the mischief possible in
controlled experiments.

<https://www.typewritten.net/writer/ev-phishing/> and
<https://stripe.ian.sh/> both took advantage of weaknesses in two
government registries to create actual dummy companies with misleading
names, then trying to get EV certs for those (with mixed success, as at
least some CAs rejected or revoked the certs despite the government
failures). At least the first of those demonstrations involved a no
longer trusted CA (Symantec). Both demonstrations caused the
researchers real name and identity to become part of the CA record,
which was hand waved away by claiming that could have been avoided by
criminal means.


Studies quoted by Tom Ritter on 24/08/2019:

>
> "By dividing these users into three groups, our controlled study
> measured both the effect of extended validation certificates that
> appear only at legitimate sites and the effect of reading a help file
> about security features in Internet Explorer 7. Across all groups, we
> found that picture-in-picture attacks showing a fake browser window
> were as effective as the best other phishing technique, the homograph
> attack. Extended validation did not help users identify either
> attack."
>
> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
>

12 years old study involving en equally outdated browser.

> "Our results showed that the identity indicators used in the
> unmodified FF3browser did not influence decision-making for the
> participants in our study interms of user trust in a web site. These
> new identity indicators were ineffectivebecause none of the
> participants even noticed their existence."
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf
>

An undated(!) study involving highly outdated browsers. No indication
this was ever in a peer reviewed journal.

> DV is sufficient. Why pay for something you don't need?
>

Unproven claim, especially by studies from before free DV without
traceable credit card payments became the norm.


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

[Jonathan Rudenberg]

On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
> <https://www.typewritten.net/writer/ev-phishing/> and
> <https://stripe.ian.sh/> both took advantage of weaknesses in two
> government registries to create actual dummy companies with misleading
> names, then trying to get EV certs for those (with mixed success, as at
> least some CAs rejected or revoked the certs despite the government
> failures).

There were no "weaknesses" or "government failures" here, everything was operating exactly as designed.

> At least the first of those demonstrations involved a no
> longer trusted CA (Symantec).

This doesn't appear to be relevant. The process followed was compliant with the EVGLs, and Symantec was picked because they were one of the most popular CAs at the time.

> Both demonstrations caused the
> researchers real name and identity to become part of the CA record,
> which was hand waved away by claiming that could have been avoided by
> criminal means.

It's not handwaving to make the assertion that a fraudster would be willing to commit fraud while committing fraud. Can you explain why you think this argument is flawed?

> Studies quoted by Tom Ritter on 24/08/2019:
>
> >

> > "By dividing these users into three groups, our controlled study
> > measured both the effect of extended validation certificates that
> > appear only at legitimate sites and the effect of reading a help file
> > about security features in Internet Explorer 7. Across all groups, we
> > found that picture-in-picture attacks showing a fake browser window
> > were as effective as the best other phishing technique, the homograph
> > attack. Extended validation did not help users identify either
> > attack."
> >
> > https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >
>

> 12 years old study involving en equally outdated browser.

Can you explain why you believe the age this study is disqualifying? What components of the study do you believe are no longer valid due to their age? Are you aware of subsequent studies showing different results?

> > "Our results showed that the identity indicators used in the
> > unmodified FF3browser did not influence decision-making for the
> > participants in our study interms of user trust in a web site. These
> > new identity indicators were ineffectivebecause none of the
> > participants even noticed their existence."
> >
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf
> >
>

> An undated(!) study involving highly outdated browsers. No indication
> this was ever in a peer reviewed journal.

This is a peer-reviewed paper that was published in the proceedings of ESORICS 2008: 13th European Symposium on Research in Computer Security, Málaga, Spain, October 6-8, 2008. Dates are actually (unfortunately) uncommon on CS papers unless the publication metadata/frontmatter is intact.

> > DV is sufficient. Why pay for something you don't need?
> >
>

> Unproven claim, especially by studies from before free DV without
> traceable credit card payments became the norm.

I don't follow your argument here. The evidence shows that DV is sufficient for phishing, as has been repeatedly explained on this thread.

[Matt Palmer]

On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via dev-security-policy wrote:
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?

Yes.

> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them. But they do raise the bar for criminals. And in my
> opinion, significantly.

Except criminals don't need them. Raising the bar doesn't help if you don't
need to go over the bar.

> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to
> the problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.

Why should Mozilla do all this work? So far, all the evidence suggests that
EV certs do not do what their advocates say they do, and have a significant
cost to browsers (code complexity, administration of EV bits, etc) and
relying parties (need to learn what the EV UI means, what it does and
doesn't claim, etc).

Instead of Mozilla continuing to take on the burden of keeping this ship
afloat, why don't the parties that benefit from selling EV certs (ie CAs) do
the hard yards to figure out what works, in a rigorous and scientific way,
and then present the results of that research to the wider community?

- Matt

[James Burton]

Jakob,

Before I touch on your comments, I wanted to point out that I am fairly
well known in the CA industry even back then and that fact might have
tainted the results sightly because I am treated some what differently to
other orders as the validation staff look more carefully at the information
presented in the order. If the order came from an anonymous body then the
chance of the success of the order is very high because the validation
staff would process it as normal without higher level intervention which
mostly happens with my orders.

The reasons why I chose Symantec:
a) They were the largest and most popular CA at that present time and most
of the largest companies in the world used that CA.
b) Symantec also provided a 30 day risk-free trial of their EV SSL and my
thinking was at the time that criminals would take advantage of that fact.

I did try Comodo first time and it did fail, the second time I tried Comodo
it worked. I publish it here:
https://www.typewritten.net/writer/ev-phishing-final/

Thank you

Burton

On Mon, Aug 26, 2019 at 8:00 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 24/08/2019 05:55, Tom Ritter wrote:

> > On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >>
> >> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
> >>> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> >>>
> >>> Whatever the merits of EV (and perhaps there are some -- I'm not
> >>> convinced either way) this data is negligible evidence of them. A DV
> >>> cert is sufficient for phishing, so there's no reason for a phisher to
> >>> obtain an EV cert, hence very few phishing sites use them, hence EV
> >>> sites are (at present) mostly not phishing sites.
> >>
> >> Can you proove that your assumption "very few phishing sites use EV
> (only) because DV is sufficient" is correct?
> >
> > As before, the first email in the thread references the studies
> performed.
>

> The (obviously outdated) studies quoted below were NOT referenced by the
> first message in this thread. The first message only referenced two
> highly unpersuasive demonstrations of the mischief possible in
> controlled experiments.
>

> <https://www.typewritten.net/writer/ev-phishing/> and
> <https://stripe.ian.sh/> both took advantage of weaknesses in two
> government registries to create actual dummy companies with misleading
> names, then trying to get EV certs for those (with mixed success, as at
> least some CAs rejected or revoked the certs despite the government

> failures). At least the first of those demonstrations involved a no
> longer trusted CA (Symantec). Both demonstrations caused the

> researchers real name and identity to become part of the CA record,
> which was hand waved away by claiming that could have been avoided by
> criminal means.
>
>

> Studies quoted by Tom Ritter on 24/08/2019:
>
> >

> > "By dividing these users into three groups, our controlled study
> > measured both the effect of extended validation certificates that
> > appear only at legitimate sites and the effect of reading a help file
> > about security features in Internet Explorer 7. Across all groups, we
> > found that picture-in-picture attacks showing a fake browser window
> > were as effective as the best other phishing technique, the homograph
> > attack. Extended validation did not help users identify either
> > attack."
> >
> > https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >
>

> 12 years old study involving en equally outdated browser.
>

> > "Our results showed that the identity indicators used in the
> > unmodified FF3browser did not influence decision-making for the
> > participants in our study interms of user trust in a web site. These
> > new identity indicators were ineffectivebecause none of the
> > participants even noticed their existence."
> >
> >
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf
> >
>

> An undated(!) study involving highly outdated browsers. No indication
> this was ever in a peer reviewed journal.
>

> > DV is sufficient. Why pay for something you don't need?
> >
>

> Unproven claim, especially by studies from before free DV without
> traceable credit card payments became the norm.
>
>

> 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

[Jakob Bohm]

On 26/08/2019 21:49, Jonathan Rudenberg wrote:
> On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
>> <https://www.typewritten.net/writer/ev-phishing/> and
>> <https://stripe.ian.sh/> both took advantage of weaknesses in two
>> government registries to create actual dummy companies with misleading
>> names, then trying to get EV certs for those (with mixed success, as at
>> least some CAs rejected or revoked the certs despite the government
>> failures).
>
> There were no "weaknesses" or "government failures" here, everything was operating exactly as designed.
>

The weakness is that those two government registries don't prevent
conflicting or obviously bad registrations, not even by retroactively
aborting the process in a few business days.

Even without the Internet this constitutes an obvious avenue for frauds.

>
>> At least the first of those demonstrations involved a no
>> longer trusted CA (Symantec).
>
> This doesn't appear to be relevant. The process followed was compliant with the EVGLs, and Symantec was picked because they were one of the most popular CAs at the time.
>

Symantec was distrusted for sloppy operation, that document version
(which we have since been informed was not the final version) claimed
that the only other CA tried did in fact reject the cert application,
indicating that issuing may not have been following "best current
practice" at the time. The revised link posted tonight reverses this
information.

>
>> Both demonstrations caused the
>> researchers real name and identity to become part of the CA record,
>> which was hand waved away by claiming that could have been avoided by
>> criminal means.
>
> It's not handwaving to make the assertion that a fraudster would be willing to commit fraud while committing fraud. Can you explain why you think this argument is flawed?
>

The EVG requires the CA to attempt to verify the personal identity
information. Stating without evidence that this verification is easily
defrauded is hand waving it away.

>
>> Studies quoted by Tom Ritter on 24/08/2019:
>>
>>>
>>> "By dividing these users into three groups, our controlled study
>>> measured both the effect of extended validation certificates that
>>> appear only at legitimate sites and the effect of reading a help file
>>> about security features in Internet Explorer 7. Across all groups, we
>>> found that picture-in-picture attacks showing a fake browser window
>>> were as effective as the best other phishing technique, the homograph
>>> attack. Extended validation did not help users identify either
>>> attack."
>>>
>>> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
>>>
>>
>> 12 years old study involving en equally outdated browser.
>
> Can you explain why you believe the age this study is disqualifying? What components of the study do you believe are no longer valid due to their age? Are you aware of subsequent studies showing different results?
>

IE7 may have had a bad UI since changed. 12 years ago, there had not
been any big outreach campaigns telling users to look for the green bar,
nor a 10 year build up of user expectation that it would be there for
such sites.

>
>>> "Our results showed that the identity indicators used in the
>>> unmodified FF3browser did not influence decision-making for the
>>> participants in our study interms of user trust in a web site. These
>>> new identity indicators were ineffectivebecause none of the
>>> participants even noticed their existence."
>>>
>>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf
>>>
>>
>> An undated(!) study involving highly outdated browsers. No indication
>> this was ever in a peer reviewed journal.
>
> This is a peer-reviewed paper that was published in the proceedings of ESORICS 2008: 13th European Symposium on Research in Computer Security, Málaga, Spain, October 6-8, 2008. Dates are actually (unfortunately) uncommon on CS papers unless the publication metadata/frontmatter is intact.
>

The link posted on Saturday did not in any way provide that publication
data, attempting to remove the "type=pdf" parameter from the link just
provided a 404, rather than the expected metadata page or link, which is
probably a failure of the citeseerx software.

Once again, the study is more than 10 years old, not reflecting the
public consciousness after years of outreach and user experience.

>
>>> DV is sufficient. Why pay for something you don't need?
>>>
>>
>> Unproven claim, especially by studies from before free DV without
>> traceable credit card payments became the norm.
>
> I don't follow your argument here. The evidence shows that DV is sufficient for phishing, as has been repeatedly explained on this thread.
>

Because no actual proof that DV versus EV makes no difference in the
current (not ancient or anecdotal) situation has been posted.

Back when DV certificates cost money, the mere act of paying for a DV
cert would leave a paper trail. It was a weak assurance, but an
assurance nonetheless. One would also presume that credit card payment
reversal due to card theft/fraud would cause the CA to revoke out of
self interest.

Remember this entire thread is all about attempts to justify Firefox
actively changing the UI to remove information, not about Firefox
creating the EV UI. Thus the burden of proof is upon those seeking
the change.

[Jonathan Rudenberg]

On Mon, Aug 26, 2019, at 20:44, Jakob Bohm via dev-security-policy wrote:
> On 26/08/2019 21:49, Jonathan Rudenberg wrote:

> > On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
> >> <https://www.typewritten.net/writer/ev-phishing/> and
> >> <https://stripe.ian.sh/> both took advantage of weaknesses in two
> >> government registries to create actual dummy companies with misleading
> >> names, then trying to get EV certs for those (with mixed success, as at
> >> least some CAs rejected or revoked the certs despite the government
> >> failures).
> >
> > There were no "weaknesses" or "government failures" here, everything was operating exactly as designed.
> >
>

> The weakness is that those two government registries don't prevent
> conflicting or obviously bad registrations, not even by retroactively
> aborting the process in a few business days.
>
> Even without the Internet this constitutes an obvious avenue for frauds.

There was no conflict. In the US, each state has unique laws around incorporation of entities. There is certainly no requirement that you can't have a corporate entity with the same name in two different states. There was nothing "conflicting" or "obviously bad" about Ian's corporation.

> >> At least the first of those demonstrations involved a no
> >> longer trusted CA (Symantec).
> >
> > This doesn't appear to be relevant. The process followed was compliant with the EVGLs, and Symantec was picked because they were one of the most popular CAs at the time.
> >
>

> Symantec was distrusted for sloppy operation, that document version
> (which we have since been informed was not the final version) claimed
> that the only other CA tried did in fact reject the cert application,
> indicating that issuing may not have been following "best current
> practice" at the time. The revised link posted tonight reverses this
> information.

The original decision not to issue an EV certificate by Comodo was arbitrary and not based on any documented practices or guidelines. Additionally, as James mentioned and you can see here, Comodo issued the certificate: https://crt.sh/?id=438718367

> >
> >> Both demonstrations caused the
> >> researchers real name and identity to become part of the CA record,
> >> which was hand waved away by claiming that could have been avoided by
> >> criminal means.
> >
> > It's not handwaving to make the assertion that a fraudster would be willing to commit fraud while committing fraud. Can you explain why you think this argument is flawed?
> >
>

> The EVG requires the CA to attempt to verify the personal identity
> information. Stating without evidence that this verification is easily
> defrauded is hand waving it away.

This is incorrect, Private Organization subjects (EVG 8.5.2) do not require any individual identity verification. Additionally, assuming that "personal identity information" can be validated without the opportunity for fraud has no basis in reality.

> >> Studies quoted by Tom Ritter on 24/08/2019:
> >>
> >>>
> >>> "By dividing these users into three groups, our controlled study
> >>> measured both the effect of extended validation certificates that
> >>> appear only at legitimate sites and the effect of reading a help file
> >>> about security features in Internet Explorer 7. Across all groups, we
> >>> found that picture-in-picture attacks showing a fake browser window
> >>> were as effective as the best other phishing technique, the homograph
> >>> attack. Extended validation did not help users identify either
> >>> attack."
> >>>
> >>> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >>>
> >>
> >> 12 years old study involving en equally outdated browser.
> >
> > Can you explain why you believe the age this study is disqualifying? What components of the study do you believe are no longer valid due to their age? Are you aware of subsequent studies showing different results?
> >
>

> IE7 may have had a bad UI since changed. 12 years ago, there had not
> been any big outreach campaigns telling users to look for the green bar,
> nor a 10 year build up of user expectation that it would be there for
> such sites.
>

Can you provide some references to these "big outreach campaigns" and documentation of the "build up of user expectation"?

> >>> "Our results showed that the identity indicators used in the
> >>> unmodified FF3browser did not influence decision-making for the
> >>> participants in our study interms of user trust in a web site. These
> >>> new identity indicators were ineffectivebecause none of the
> >>> participants even noticed their existence."
> >>>
> >>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117&rep=rep1&type=pdf
> >>>
> >>
> >> An undated(!) study involving highly outdated browsers. No indication
> >> this was ever in a peer reviewed journal.
> >
> > This is a peer-reviewed paper that was published in the proceedings of ESORICS 2008: 13th European Symposium on Research in Computer Security, Málaga, Spain, October 6-8, 2008. Dates are actually (unfortunately) uncommon on CS papers unless the publication metadata/frontmatter is intact.
> >
>

> The link posted on Saturday did not in any way provide that publication
> data, attempting to remove the "type=pdf" parameter from the link just
> provided a 404, rather than the expected metadata page or link, which is
> probably a failure of the citeseerx software.
>
> Once again, the study is more than 10 years old, not reflecting the
> public consciousness after years of outreach and user experience.

What evidence do you have of this "public consciousness"? As referenced previously paypal.com does not have any EV UI in the most popular browser/OS after years of having EV treatment and I haven't seen any evidence of this being noticed outside the security community. All of the evidence (including peer-reviewed scientific studies) points to users completely ignoring/being unaware of EV UI. I'd be very interested to see your evidence to the contrary.

> >>> DV is sufficient. Why pay for something you don't need?
> >>>
> >>
> >> Unproven claim, especially by studies from before free DV without
> >> traceable credit card payments became the norm.
> >
> > I don't follow your argument here. The evidence shows that DV is sufficient for phishing, as has been repeatedly explained on this thread.
> >
>

> Because no actual proof that DV versus EV makes no difference in the
> current (not ancient or anecdotal) situation has been posted.
>
> Back when DV certificates cost money, the mere act of paying for a DV
> cert would leave a paper trail. It was a weak assurance, but an
> assurance nonetheless. One would also presume that credit card payment
> reversal due to card theft/fraud would cause the CA to revoke out of
> self interest.
>
> Remember this entire thread is all about attempts to justify Firefox
> actively changing the UI to remove information, not about Firefox
> creating the EV UI. Thus the burden of proof is upon those seeking
> the change.

What are you arguing here? Why does it matter that DV had a paper trail?

There's no burden of proof required for Firefox to remove this UI, but all of the reliable evidence supports their decision.

[Peter Gutmann]

Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

><https://www.typewritten.net/writer/ev-phishing/> and
><https://stripe.ian.sh/> both took advantage of weaknesses in two
>government registries

They weren't "weaknesses in government registries", they were registries
working as designed, and as intended. The fact that they don't work in
they way EV wishes they did is a flaw in EV, not a problem with the
registries.

>Both demonstrations caused the researchers real name and identity to become
>part of the CA record, which was hand waved away by claiming that could
>have been avoided by criminal means.

It wasn't "wished away", it's avoided without too much trouble by criminals,
see my earlier screenshot of just one of numerous black-market sites where
you can buy fraudulent EV certs from registered companies. Again, EV may
wish this wasn't the case, but that's not how the real world works.

>12 years old study involving en equally outdated browser.

So you've published a more recent peer-reviewed academic study that
refutes the earlier work? Could you send us the reference?

Peter.

[Cynthia Revström]

>
> Because no actual proof that DV versus EV makes no difference in the
> current (not ancient or anecdotal) situation has been posted.
>
>

To me that sounds like you are suggesting that we prove that nothing
happened, which is pretty much impossible.
Why don't you or the CAs offering EV prove that it did have a significant
impact?

- Cynthia

[Jakob Bohm]

On 27/08/2019 08:03, Peter Gutmann wrote:
> Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> writes:
>
>> <https://www.typewritten.net/writer/ev-phishing/> and
>> <https://stripe.ian.sh/> both took advantage of weaknesses in two
>> government registries
>
> They weren't "weaknesses in government registries", they were registries
> working as designed, and as intended. The fact that they don't work in
> they way EV wishes they did is a flaw in EV, not a problem with the
> registries.
>

"Working as designed" doesn't mean "working as it should".

The confusion that could be created online by getting EV certificates
matching those company registrations were almost the same as those that
could be created in the offline world by the registrations directly.

>> Both demonstrations caused the researchers real name and identity to become
>> part of the CA record, which was hand waved away by claiming that could
>> have been avoided by criminal means.
>
> It wasn't "wished away", it's avoided without too much trouble by criminals,
> see my earlier screenshot of just one of numerous black-market sites where
> you can buy fraudulent EV certs from registered companies. Again, EV may
> wish this wasn't the case, but that's not how the real world works.
>

The screenshots you showed were for code signing EV certificates, not
TLS EV certificates. They seem related to a report a few years ago that
spurned work to check the veracity of those screenshots and create
appropriate countermeasures.

>> 12 years old study involving en equally outdated browser.
>
> So you've published a more recent peer-reviewed academic study that
> refutes the earlier work? Could you send us the reference?
>

These two studies are outdated because they study the effects in a
different overall situation (they were both made when the TLS EV concept
had not yet been globally deployed). They are thus based on entirely
different facts (measured and unmeasured) than the situation in 2019.

Very early in this thread someone quoted from a very recent study
published at usenix, comparing the prevalence of malicious sites with
different types of certificates. The only response was platitudes,
such as a emphasizing a small number being nonzero.

Someone is trying very hard to create a fait acompli without going
through proper debate and voting in relevant organizations such as
the CAB/F. So when challenged they play very dirty, using every
rhetorical trick they can find to overpower criticism of the action.

[James Burton]

Companies House (
http://resources.companieshouse.gov.uk/serviceInformation.shtml#compInfo)
says "We carry out basic checks on documents received to make sure that
they have been fully completed and signed, but we do not have the statutory
power or capability to verify the accuracy of the information that
companies send to us. The fact that the information has been placed on the
public record should not be taken to indicate that Companies House has
verified or validated it in any way."

Dun and Bradstreet takes a copy of this information without any
verification checking and can be easily updated here
https://www.dnb.co.uk/utility-pages/data-update.html again without any
verification checks.

When a CA is vetting an organization for an EV certificate, what
information is actually vetted? Does the organization operate at that
address? Am I actually speaking to the director James Burton in the
verification call?

The correct way to vet a UK company would be to:
1. The CA checks Companies House to check if the company is incorporated.
2. The CA sends a letter with verification code to the company address
listed on Companies House.
3. The CA requests the company to send them a bank statement / tax bill to
prove operation.
4. Once the company has sent the information provided in (3) and is it
confirmed by CA then (5) otherwise (3).
5. Once the company receives the letter with verification code then (6)
otherwise vetting on hold until company receives letter with verification
code.
6. The CA initiates video call with the director at the listed at Companies
House and then the CA does the following:
a) Asks the director to hold up his/her passport to the side of their face
to confirm that the face matches the passport photo and then the CA
confirms the details such full name and DOB matches the information printed
on the passport.
b) The CA asks the director to hold up the verification letter in front of
the camera to confirm company address.
c) The CA then calls the company number listed on 3rd party register
(automated phone call like Google verification phone call) and the director
tell that verification code to the CA to confirm the phone number is
belongs to the company.
d) Signs the agreement.
7. That's it.

On Tue, Aug 27, 2019 at 9:21 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 27/08/2019 08:03, Peter Gutmann wrote:

> > Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> writes:
> >
> >> <https://www.typewritten.net/writer/ev-phishing/> and
> >> <https://stripe.ian.sh/> both took advantage of weaknesses in two
> >> government registries
> >
> > They weren't "weaknesses in government registries", they were registries
> > working as designed, and as intended. The fact that they don't work in
> > they way EV wishes they did is a flaw in EV, not a problem with the
> > registries.
> >
>

> "Working as designed" doesn't mean "working as it should".
>
> The confusion that could be created online by getting EV certificates
> matching those company registrations were almost the same as those that
> could be created in the offline world by the registrations directly.
>
>

> >> Both demonstrations caused the researchers real name and identity to
> become
> >> part of the CA record, which was hand waved away by claiming that could
> >> have been avoided by criminal means.
> >
> > It wasn't "wished away", it's avoided without too much trouble by
> criminals,
> > see my earlier screenshot of just one of numerous black-market sites
> where
> > you can buy fraudulent EV certs from registered companies. Again, EV may
> > wish this wasn't the case, but that's not how the real world works.
> >
>

> The screenshots you showed were for code signing EV certificates, not
> TLS EV certificates. They seem related to a report a few years ago that
> spurned work to check the veracity of those screenshots and create
> appropriate countermeasures.
>

> >> 12 years old study involving en equally outdated browser.
> >
> > So you've published a more recent peer-reviewed academic study that
> > refutes the earlier work? Could you send us the reference?
> >
>

> These two studies are outdated because they study the effects in a
> different overall situation (they were both made when the TLS EV concept
> had not yet been globally deployed). They are thus based on entirely
> different facts (measured and unmeasured) than the situation in 2019.
>
> Very early in this thread someone quoted from a very recent study
> published at usenix, comparing the prevalence of malicious sites with
> different types of certificates. The only response was platitudes,
> such as a emphasizing a small number being nonzero.
>
> Someone is trying very hard to create a fait acompli without going
> through proper debate and voting in relevant organizations such as
> the CAB/F. So when challenged they play very dirty, using every
> rhetorical trick they can find to overpower criticism of the action.
>
>
>
> 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

[James Burton]

Resend again to fix spelling errors and add extra details

The correct way to vet a UK company would be to:
1. The CA checks Companies House to check if the company is incorporated.
2. The CA sends a letter with verification code to the company address
listed on Companies House.
3. The CA requests the company to send them a bank statement / tax bill to
prove operation.
4. Once the company has sent the information provided in (3) and is it
confirmed by CA then (5) otherwise (3).
5. Once the company receives the letter with verification code then (6)
otherwise vetting on hold until company receives letter with verification
code.

6. The CA initiates video call with the director who is listed at Companies

House and then the CA does the following:

a) The CA asks the director to hold up his/her passport to the side of

their face to confirm that the face matches the passport photo and then the

CA confirms the details such as full name and DOB matches the information
printed on the passport.
(optionally: For high profile companies the CA could also ask for the
passport to be countersigned and put the video call on hold while they
confirm the countersignature with the individual.)
(optionally: For high profile companies the CA could also ask for the
incorporation certificate to be countersigned and put the video call on
hold while they confirm the countersignature with the individual.)

b) The CA asks the director to hold up the verification letter in front of
the camera to confirm company address.

c) The CA calls the company number listed on 3rd party register (automated
phone call like the Google verification phone call) and the director tell
that verification code to the CA to confirm the phone number belongs to the

company.
d) Signs the agreement.
7. That's it.

This method confirms that:
a) The company is in active operation at the address listed on Companies
House.
b) The company phone number is in active operation at the company.
c) The director of the company has been vetted and confirmed certificate
request by signing the agreement.

Burton

>> > Jakob Bohm via dev-security-policy <
>> dev-secur...@lists.mozilla.org> writes:
>> >
>> >> <https://www.typewritten.net/writer/ev-phishing/> and
>> >> <https://stripe.ian.sh/> both took advantage of weaknesses in two
>> >> government registries
>> >
>> > They weren't "weaknesses in government registries", they were registries
>> > working as designed, and as intended. The fact that they don't work in
>> > they way EV wishes they did is a flaw in EV, not a problem with the
>> > registries.
>> >
>>

>> "Working as designed" doesn't mean "working as it should".
>>
>> The confusion that could be created online by getting EV certificates
>> matching those company registrations were almost the same as those that
>> could be created in the offline world by the registrations directly.
>>
>>

>> >> Both demonstrations caused the researchers real name and identity to
>> become
>> >> part of the CA record, which was hand waved away by claiming that could
>> >> have been avoided by criminal means.
>> >
>> > It wasn't "wished away", it's avoided without too much trouble by
>> criminals,
>> > see my earlier screenshot of just one of numerous black-market sites
>> where
>> > you can buy fraudulent EV certs from registered companies. Again, EV
>> may
>> > wish this wasn't the case, but that's not how the real world works.
>> >
>>

>> The screenshots you showed were for code signing EV certificates, not
>> TLS EV certificates. They seem related to a report a few years ago that
>> spurned work to check the veracity of those screenshots and create
>> appropriate countermeasures.
>>

>> >> 12 years old study involving en equally outdated browser.
>> >
>> > So you've published a more recent peer-reviewed academic study that
>> > refutes the earlier work? Could you send us the reference?
>> >
>>

[Leo Grove]

>
> There are also opportunities for browsers here. I have to admit I
> primarily use Google Chrome, rather than Firefox, so my observations may be
> a little tainted, but I see various places where signals far more valuable
> than the green lock could be implemented. Consider that most browsers
> recognize credit card entry fields -- wouldn't it be great if clicking on
> one on an EV site showed a little drop down under the input box that said
> "[CA name here] has certified that [EV info here] is receiving your credit
> card information"?
>

I like this idea, but putting my browser UI designer hat on, I would ask myself some questions. Would these indicators appear in input and textarea html tags? Or should it be at the form tag level? What about form elements that completely hide the native appearance via css? What about ajax and/or reactive apps? Then I would think it's just simpler to put the EV UI in the address bar. I'm curious if the browser developers went through this process, and we all ended up with what we have now. It might be time to (re)examine this.

[Josef Schneider]

Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via dev-security-policy wrote:
> > Sure I can register a company and get an EV certificate for that company.
> > But can I do this completely anonymous like getting a DV cert?
>
> Yes.

Not legally probably and this also depends on the jurisdiction. Since an EV cert shows the jurisdiction, a user can draw conclusions from that.

> > Nobody is arguing that EV certificates are perfect and everything is good
> > if you use them. But they do raise the bar for criminals. And in my
> > opinion, significantly.
>
> Except criminals don't need them. Raising the bar doesn't help if you don't
> need to go over the bar.
>

But removing the bar is also not the correct solution. If you find out that the back door to your house is not secured properly, will you remove the front door because it doesn't matter anyway or do you strengthen the back door?

> > What I propose is for mozilla to not say "Fuck it, it's not working, just
> > remove it!" but instead try to focus on finding a better UX solution to
> > the problem that end users are not aware if a site that should have an EV
> > certificate is not presenting one.
>
> Why should Mozilla do all this work? So far, all the evidence suggests that
> EV certs do not do what their advocates say they do, and have a significant
> cost to browsers (code complexity, administration of EV bits, etc) and
> relying parties (need to learn what the EV UI means, what it does and
> doesn't claim, etc).

Why should Mozilla do work to make the situation worse? The current EV validation information in the URL works and is helpful to some users (maybe only a small percentage of users, but still...). Why is mozilla interested in spending money making the situation worse. If mozilla doesn't care about the empowerment of their users, the default would be to not change anything, not actively making it worse.

EV certificates do make more assurances about the certificate owner than DV certificates. This is a fact. This information can be very useful for someone that understands what it means. Probably most users don't understand what it means. But why not improve the display of this valuable information instead of hiding it?

Certificates cannot magically bring security. Certificates are about identity. But the fact that the owner of the website somebank.eu is the owner of the domain somebank.eu is not that helpful in determining the credibility. But the information that the owner of somebank.eu is a incorporated company from Germany officially called "Somebank AG" is more valuable.
Maybe some people don't care and enter their account data happily at s0m1b4nk.xyz, maybe most people do. We don't know and we probably can't know how many people stopped and thought if they are actually at the correct website because the green bar was missing. But I am certain that it was more than zero.

What mozilla now is proposing is: EV certificates have no use in any situation so basically remove them. I don't think that's true.

I am not a UX designer, but I am sure there are methods to incorporate this valuable information from EV certificates in a way that it is helpful to users.

Why not for example always open a small overlay with information when someone starts entering data in a password field? Something like "You are entering a password at web.page. You visited this page 5 times before, first on August 4th 2019. We don't know anything about the owner" or for EV "You are entering a password at web.page. You visited this page 5 times before, first on August 4th 2019. This server is run by "WebPage GmbH" from Vienna, Austria [fancy flag picture]".

As said, I am not a UX designer (or any graphical type of designer) so probably this idea is stupid. But my point is that the information in an EV certificate is useful **to the user** and should be presented in a way to empower the user and not be hidden.

- Josef

[Kirk Hall]

Most of the comments against EV certificates on this list have been focused on whether or not the current Firefox EV UI is relied on by Firefox users to make security decisions. (Actually, I have only seen a Google paper on this issue in Chrome, no research from Firefox.)

But there is an ecosystem of anti-phishing browser filters (e.g., Google Safe Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as well as others that use the current identity information in EV certs to make better determinations of positive and false positive phishing sites and thereby protect users, as well as for other user security purposes.

Many on this discussion would like to see EV certs disappear entirely and move all websites to DV certs. But remember, if EV certs disappear, so does all the EV identity information that’s being used today by security software to protect users.

So my question to those who want EV certificates to disappear is this: OK, then what is *your* plan for protecting users? Browser filters will be weaker without EV information (and some browser filters today miss 20% of phishing sites at zero hour, according to NSS studies). How will you replace the EV information that’s being used today by phishing filters and services to protect users?

Any decision on removing the EV UI in Firefox should consider all the related impacts on user security, and not just focus on a single issue (namely, “Do users rely on the EV UI?”), especially when the current Firefox EV UI is doing no harm.

[Ryan Sleevi]

(Posting in a personal capacity)

On Wed, Aug 28, 2019 at 7:01 PM Kirk Hall via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Most of the comments against EV certificates on this list have been
> focused on whether or not the current Firefox EV UI is relied on by Firefox
> users to make security decisions. (Actually, I have only seen a Google
> paper on this issue in Chrome, no research from Firefox.)
>
> But there is an ecosystem of anti-phishing browser filters (e.g., Google
> Safe Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as
> well as others that use the current identity information in EV certs to
> make better determinations of positive and false positive phishing sites
> and thereby protect users, as well as for other user security purposes.
>
> Many on this discussion would like to see EV certs disappear entirely and
> move all websites to DV certs. But remember, if EV certs disappear, so
> does all the EV identity information that’s being used today by security
> software to protect users.
>
> So my question to those who want EV certificates to disappear is this: OK,
> then what is *your* plan for protecting users? Browser filters will be
> weaker without EV information (and some browser filters today miss 20% of
> phishing sites at zero hour, according to NSS studies). How will you
> replace the EV information that’s being used today by phishing filters and
> services to protect users?
>

These are very reasonable concerns, and a very valid question to ask.
However, with respect to Mozilla's original posting here, or the
announcements from the Chrome team, it does not sound as if any of the
browsers are presently proposing removing EV.

So perhaps that's worthy of a separate conversation?

> Any decision on removing the EV UI in Firefox should consider all the
> related impacts on user security, and not just focus on a single issue
> (namely, “Do users rely on the EV UI?”), especially when the current
> Firefox EV UI is doing no harm.
>

I may have missed something in the hundred messages in this thread, but
could you highlight what other "impacts on user security" were identified
that are specific to the UI, and that are not intrinsically linked to the
question of "Do users rely on the EV UI"? Perhaps it might be worth
exploring Peter Bowen's questions, in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/TaXQb7VcAQAJ
, or those offered in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/gBqfc3XPAAAJ
, which seemed to identify both the question of harm and how this change
would not negatively impair other improvements.

With respect to "doing no harm," a position others on the thread have also
mentioned, I don't know that conclusion has been demonstrated. Could you
point to any peer-reviewed research or literature that suggests it does no
harm? There appears to be a sizable and growing body with respect to
Human-Computer Interaction, as well as within the broader behavioural
sciences, that the studies around EV have referenced or mentioned in terms
things like "alarm fatigue" and "information overload".

Much like the discussion around correlation versus causation, it seems like
there might be two separable pieces:
1) A question about whether users rely on EV UI
2) A question about whether the EV UI causes harm

With respect to the second question, it seems folks have identified that if
the answer to 1 is yes, then the answer to 2 is also yes - for example, the
mentioned-in-the-original-post Stripe example causing user confusion, or
situations like the organization "Identity Verified".
If the answer to 1 is no, then is it reasonable to infer that it causes
harm both in terms of software maintenance costs to support that UI, but
also in that it may lead users to believe the answer to 1 is or should be
yes, thus bringing us back to the harm caused when users rely upon it.

Perhaps I've missed some research on it doing no harm? Given the issues
identified, that would seem to be the burden to demonstrate: folks have
provided example of it doing harm, so it doesn't seem the conclusion is
there?