
Extended Validation Certificates Are Really Dead - dyates
https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/
======
Ajedi32
It's actually kind of unfortunate, as in some ways an organization's name is a
much more meaningful expression of identity than a domain name is. When I
visit the website for my bank, I don't really care that the entity I'm
communicating with owns "mybank.com". What I, and I suspect most people, are
really concerned with is that the entity they're communicating with is the
same physical, real-world organization they opened a bank account with in the
past.

The problem is that legal corporation names are much harder to verify than
domain names, and even once verified they don't always match user expectations
(as Ian Carroll so aptly demonstrated with his Stripe Inc. certificate).
Furthermore, and perhaps partially as a result of the aforementioned issues,
browsers don't treat EV certificates in a way which would allow any meaningful
security guarantees to be built on top of them.

I wonder if there are ways this situation could be improved. Brand names, for
example, are probably more likely to match user expectations than legal
company names. Perhaps an alternative to EV could be built around that idea.

~~~
skybrian
The names that people are familiar with come from branding and publicity -
that is, advertising, news, social media, and so on. This affects the web
pages that search engines crawl, what users search for, and also which
websites rank higher. I'm not sure how someone would do better than search
engines? Searching for the company you're looking for usually works.

You can imagine inventing a more systematic approach to assigning names, but
it would be like using scientific names for animals instead of common names.
Domain names serve this purpose already. What we really want is to document
popular usage.

One systematic approach to tracking popular usage might be to treat this like
creating a dictionary. However the dictionary compilers are always going to
lag popular usage. This is why Yahoo's directory-based approach lost out to
Google. The closest thing we have now is Wikipedia and Google gets that data
via crawling.

I guess you could say that human languages are not entirely secure due to
being a bit nebulous, but it's the best we have for humans referring to things
they remember. If you want to be precise, you need to remember, record, or
communicate the domain name.

~~~
heavenlyblue
.ac.uk is reserved only for education.

Simply having an e-mail on one of these domains implies access to e.g. free
GitHub accounts.

We could have something akin to .bank.uk for banking purposes (you are only
allowed go have one if you have a banking license).

~~~
davchana
I think the new gTld .bank is marketing itself for banks in that way, making
sure only real banks get.bank

------
Ajedi32
Direct link to explainer doc in the Chromium source:
[https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-
to-page-info.md) (Permalink version
[https://chromium.googlesource.com/chromium/src/+/bccea73462d...](https://chromium.googlesource.com/chromium/src/+/bccea73462da42b6366dd4d8dc391ee07c615312/docs/security/ev-
to-page-info.md))

Chrome mailing list announcement:
[https://groups.google.com/a/chromium.org/forum/#!topic/secur...](https://groups.google.com/a/chromium.org/forum/#!topic/security-
dev/h1bTcoTpfeI)

Firefox mailing list announcement:
[https://groups.google.com/forum/#!topic/firefox-
dev/6wAg_Ppn...](https://groups.google.com/forum/#!topic/firefox-
dev/6wAg_PpnlY4)

Firefox bugzilla issue:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1572936](https://bugzilla.mozilla.org/show_bug.cgi?id=1572936)

------
ocdtrekkie
The irritating thing is that EV is the closest thing to a useful thing PKI can
provide[1]. And the only reason it's being pushed out is because Google
doesn't like it and hence Chrome has been retiring it. Google's previously
indicated it essentially wants to build it's own system[2] that is...
effectively EV. So this is probably the death of a problematic but fixable
open system which will be replaced by a proprietary Google-owned one.

Firefox, is, of course, following the monopoly lead.

[1]HTTPS encryption itself doesn't meaningfully require public key
infrastructure, it's just that without PKI, you don't know who sent the
encrypted traffic. Since domains are terrible "identities" and it's common for
large organizations to use many of them that sound similar to scam domains,
domain validation really doesn't tell anyone anything about whether or not
they're talking to a trustworthy entity.

[2]Basically Google said it wants to "invent" EV certs here, late last year:
[https://www.wired.com/story/google-wants-to-kill-the-
url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

~~~
chimeracoder
> [1]HTTPS encryption itself doesn't meaningfully require public key
> infrastructure, it's just that without PKI, you don't know who sent the
> encrypted traffic. Since domains are terrible "identities" and it's common
> for large organizations to use many of them that sound similar to scam
> domains, domain validation really doesn't tell anyone anything about whether
> or not they're talking to a trustworthy entity.

It is trivial to get an EV cert for a company that has the same name as a
trustworthy entity[0]. There is nothing in the design of EV that prevents
this, and name collisions between corporate entities are common and acceptable
practice[1].

[0] [https://stripe.ian.sh/](https://stripe.ian.sh/)

[1] Trademarks are a different matter, but _getting_ an EV cert for a company
that has the same incorporated name as a different company in a different
state is completely legal.

~~~
wahern
> Trademarks are a different matter, but getting an EV cert for a company that
> has the same incorporated name as a different company in a different state
> is completely legal.

It is legal. But it's also much more easily traced (even through various shell
companies as process agents want to get paid), which compared to the way most
crime works on the internet is infinitely more risky for the perpetrator.

Also, companies like banks regular scour business records for similarly named
businesses, which means the window for fraud is smaller. I'm not surprised
that someone would find it easy to spoof Stripe, but let's see how long they
manage to spoof PayPal or Bank of America. If they don't already, EV
certificates should issue only after the named entity has existed for N months
(or years).

~~~
gruez
>Also, companies like banks regular scour business records for similarly named
businesses, which means the window for fraud is smaller

can't they also scour the certificate transparency logs as well? I'd imagine
that's easier and more reliable than scouring the public records of hundreds
or thousands of jurisdictions.

~~~
wahern
I'm sure they can and do. But it's not an either-or situation. Also, AFAIU, EV
certs won't even _issue_ without heightened scrutiny regarding domain name
ambiguity.

When SSL first came out there was a heavy focus on informing the public to
check for the padlock; that if they were worried about fraud then checking for
the padlock was a concrete step they could take to help reassure themselves.
But there was never a similar campaign regarding EV certs. There were
attempts, but they were short-lived and not nearly as aggressive. Partly
that's because the messaging was more difficult, but it _could_ have been
done.

Google _could_ have put more effort behind it. But they weren't interested,
partly because as someone else mentioned they have their own ideas about how
to move forward, ideas that just happen to fit in better with Google's
commercial interests. Some of those ideas are reasonable, but again this isn't
an either-or situation. They're making it either-or.

------
herpderperator
I'm pretty disappointed by this. I definitely trust what I see a lot more when
I see the legal entity name in the URL through an EV cert. I don't really
understand why it's being removed. It's more difficult to get an EV cert
because of the additional legal process, and it makes it clear to the user
that the website is run by that entity, which is exactly what we want...

With Google removing [https://](https://) from the URL and EV being gone, I
don't even know what to trust anymore.

~~~
dbalan
I don't have any solutions to your last statement, but one of the problem is
that legal name of the entity matching doesn't really mean its the same entiy
you think it is - the example ( also in the original page):
[https://stripe.ian.sh/](https://stripe.ian.sh/)

~~~
herpderperator
When I visit that page I don't see an EV banner in my Chrome, version
76.0.3809.100. It seems like I'm meant to according to the document?

Edit: I see, it says it was revoked. Well that makes sense:

> Edit (April 29th, 2018): This site no longer uses an EV certificate. Comodo
> arbitrarily revoked — without any notice — the first certificate, saying
> this site was made with the intent to mislead. GoDaddy issued us a new one
> on 04/11/2018, but revoked it later that day, stating that the site was
> fraudulent.

So OBVIOUSLY the CAs are trying (maybe not as hard as we'd hope) to make sure
EV is used responsibly, so why kill EV? Why not just improve the process a
little bit more to make it unlikely to give an EV cert that clearly intends to
mislead?

> It is notable that neither company believes they mis-issued the certificate.

What? They clearly revoked both and specified the reason, so does that not
make the mis-issuance implicit?

~~~
calebegg
Comodo said the revocation was a mistake:

[https://sectigo.com/blog/on-comodo-cas-recent-revocation-
of-...](https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-an-ssl-
certificate-for-kentucky-based-stripe-inc)

------
tgsovlerkhgsel
EV had one advantage: It allowed browser vendors to push for improved
standards (like Certificate Transparency adoption) with minimal push-back.
It's easy to complain about expensive security measures for run-of-the-mill
certificates, it's much harder to argue about such measures for special extra-
secure ones.

And since CAs wanted the EV cash cow, they implemented CT and other
improvements, and once they had the code, they had little reason to object
against applying the same requirement to regular certificates.

Another advantage is that when my bank requires me to enter a verified-by-visa
password on lookslikephishingbutreallyismybank.com, I can actually verify
(with a reasonable degree of certainty) who the site belongs to - even if they
could, attackers generally won't go through the effort of getting a similar
name. But that's a power user feature.

------
SAI_Peregrinus
Good riddance, IMO. They never meant much to begin with, the validation
procedures were basically "can you pay the fee?", and they only added to user
confusion.

------
stefan_
I don't understand the glee, _schadenfreude_ even. So because the UI side of
things didn't work out, it is an improvement that now all certificates will go
back to the "crusty Perl script fetching a side-channel secret from a
webserver" method of "validation"?

On the contrary, we should just push for extended validation on all
certificates. Whether they come with a fancy UI or not.

Because if we are on the topic of https UI effectiveness, then I'm pretty sure
_everything we have right now_ is doing a horrible job and could be removed
with much the same tenuous reasoning.

~~~
Znafon
Why push for extended validation of there is no security benefits and the user
experience is the same?

I remember that someone had successfully got an extended certificate for
"Stripe, Inc".

Things like certificate transparency log monitoring seems better than EV to
improve security.

~~~
stefan_
Maybe EV isn't the answer. But there is opportunity for something else out
there, because right now https is not living up to the "authentication"
promise when you have Firefox, Chrome et al. kotau to company proxies and all
kinds of dubious state CAs in the trust root.

That's before you get to the UI failures, where phishers can trivially get
that lock for their microssoft.com domains.

~~~
hannob
> But there is opportunity for something else out there, because right now
> https is not living up to the "authentication" promise when you have
> Firefox, Chrome et al. kotau to company proxies and all kinds of dubious
> state CAs in the trust root.

There's already a lot of things being done to improve the situation. Honest
question: Are you aware of them? Do you know Certificate Transparency? Have
you followed the intense discussion about Dark Matter? Do you know what the
Baseline Requirements are? Do you know how Webauthn prevents Phishing?

------
jillesvangurp
I just replaced an EV certificate with a free AWS provided one on our website.
We jumped through a lot of hoops a few years ago to get our EV certificate.
This was a tedious process that involved form filling, credit cards, lots of
waiting and poorly documented ways of handling the actual certificates. I
actually had to append some text files to that were sent via email to get a
valid thing that nginx actually understood, etc. I lost non trivial amounts of
time with this. Because it was so tedious, we went for long lived
certificates. When we switched to amazon we preserved our investment and
uploaded the certificate to AWS and used it on an ALB.

Since then the market has changed a lot. E.g. Letsencrypt happened and several
companies, including amazon, now offer very convenient ways of getting
certificates. So, last week the process was as follows: 1) I created anew
certificate in the region where I needed it. 2) after waiting for it to
deploy, I selected it from a drop down on the ALB where it was needed. End of
story. It will take care about renewal, adds no extra cost, and requires no
fiddling with text files.

------
bronzeage
seems like you are completely missing the use case, if you think EV
certificates are for frequently visited website.

I, for one, always make sure my bank has EV before I enter the password. the
fact that most people don't doesn't change the fact that it does provide
additional trust for those who are aware. security isn't all or nothing.

the second use case is when you first visit a website, which potentially asks
for credit card number or anything sensitive, it does improve your trust and
reduces the friction with lesser known websites. of course PayPal, as a well
known and trusted website doesn't need it - nobody is asking themselves if
they should trust PayPal. again, it's probably not a security boundary, and
it's probably not impossible to generate bogus ev certs, it's better than
nothing.

~~~
rocqua
Paypal is an interesting case [1]. Whether they served an EV-cert differed
based on browser. If EV worked, that would mean people who switched browsers
would refuse to use paypal.

And yet, there are no reports of people thinking their paypal is untrusted.
Nor did paypal decide to roll out EV everywhere because they were losing
users.

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

edit: Claimed that EV differed based on location, but it was based on browser.

------
cevn
What about for Windows development? I just ordered one through my company in
order to bypass 'untrusted app' dialogs that my non tech savvy users can't
figure out.

~~~
Someone1234
Not all Code Signing certificates are Extended Validation. Non-EV Code Signing
certificates bypass that warning (Authenticode). So it has no impact.

Code Signing will still be $175 too expensive and still work just as they
have.

~~~
zanderz
MS still requires that drivers be signed with an EV cert
[https://docs.microsoft.com/en-us/windows-
hardware/drivers/da...](https://docs.microsoft.com/en-us/windows-
hardware/drivers/dashboard/get-a-code-signing-certificate) And it supposedly
does help add some SmartScreen reputation, but that system is totally opaque
and there is no way to quantify just what the EV cert adds.

~~~
judge2020
New EV certificates don't just help with SmartScreen, they completely bypass
it. Regular Windows code signing is the smartscreen booster.

------
vbezhenar
Why do we need multiple CA now? Keep letsencrypt and distrust everyone else.
Their business is dead anyway. Domain validation is an automated process and
does not require much income to keep working. Just like DNS Roots works
without competition.

~~~
Ajedi32
Because then you'd be centralizing control of certificate validation in a
single corporation, and creating a too-big-to-fail CA that _can 't_ be
distrusted if it screws up for fear of breaking the entire internet.

~~~
vbezhenar
We will have enough time to switch to the new CA if necessary. And ACME
protocol is independent, so software just needs to update some configuration
values.

Anyway letsencrypt already serves 80% of market. So it's already too big to
fail, I don't see much difference between 80% and 100%. But dozens of random
CA roots in my browser do bother me.

~~~
eridius
> _Anyway letsencrypt already serves 80% of market. So it 's already too big
> to fail, I don't see much difference between 80% and 100%._

The difference is all the big websites still pay for certs, so if LE is
distrusted then your bank will still work, google.com will still work,
apple.com will still work, etc.

------
nailer
As someone with a direct interest in this (I run
[https://certsimple.com](https://certsimple.com), a startup that focuses on
steamlining the EV verification process), this is predictable but still
hilarious:

> Through our own research as well as a survey of prior academic work, the
> Chrome Security UX team has determined that the EV UI does not protect users
> as intended (see Further Reading in the Chromium document). Users do not
> appear to make secure choices (such as not entering password or credit card
> information) when the UI is altered or removed, as would be necessary for EV
> UI to provide meaningful protection.

Chrome has never tested a verification marker that resembles ANY of the common
standards for verification used on Twitter, Whatsapp, Facebook, Apple's App
Store or Google Play.

No research into better indicators has been done because Google do not wish to
do research into better indicators. Decisions are:

\- made by one individual who believes users should be able to detect bad
sites because they "don't look right"

\- supported by another person who thinks users can use DNS to decider whether
sites are real. Ask a regular web user, or even an infosec expert to determine
which out of "google.im", "google.co.uk" and "withgoogle.com" is actually
controlled by Google.

\- and further supported by somebody else who thinks a study of IE7's UI:

    
    
        foo.com                            VeriSign [US]
    

is relevant research (see this article).

Yes UX designed in the mid-2000s, prior to modern verification standards, is
sub optimal.

I've suggested Google's UX people investigate better alternatives for years.
They're not interested.

The CAs aren't that much better either (being slow to realise how much the
market is changing around them) but Google are absolutely not interested in
finding out what would be possible with a modern verification UI, or making
sure users know who they're connected to.

~~~
Scott_Helme_
As the organisations that stand to benefit financially from selling these
indicators, perhaps it's CAs that should invest in the research? CAs seem to
constantly point at the browsers as the party responsible for doing that
research, but I don't see why.

~~~
nailer
Totally agreed CAs dropped the ball on research too. It's not an either/or
thing: browsers makers need to ensure their security UX helps people
understand what they're connecting to and CAs need to do the same and
additionally ensure their verification processes are robust.

~~~
Scott_Helme_
But, didn't browser vendors do that and that's why the EV indicator is being
moved to a less prominent location?..

~~~
nailer
No, browser vendors have not tested verification markers that are consistent
with other platforms. See the top post in this thread.

~~~
Scott_Helme_
That's not what I asked, that's a straw man.

Browser vendors have tested the efficacy of the current EV indicator,
resulting in the current action.

If you feel that testing an alternative indicator consistent with other
platforms is a good idea, then perhaps that's where the CAs should start their
research.

~~~
nailer
>>>> browsers makers need to ensure their security UX helps people understand
what they're connecting to

>>> But, didn't browser vendors do that

>> No, browser vendors have not tested verification markers that are
consistent with other platforms.

> That's not what I asked, that's a straw man.

Doesn't seem like much of a straw man to me. Investigating whether browser
security UX helps people understand what they're connecting to logically
includes looking at designs other than the current one.

> then perhaps that's where the CAs should start their research.

Yes. And browsers too.

