
Are EV certificates worth the paper they're written on? - pgl
https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/
======
nlh
I would argue that the top 10 sites aren’t using EV because they don’t _need_
to use EV, precisely because they’re top 10 sites.

If I’m visiting Amazon, I’m pretty sure that I’m getting the security I’m
expecting simply by seeing Amazon’s domain, the pages I recognize, and some
semblance of SSL.

It’s the lesser-known sites, I think, where this sort of “trust” (for some
version of trust) matters more — random-ecommerce-site.com doesn’t have the
brand value or trust factor of Amazon, so they need every (perceived)
advantage they can get, EV being one.

~~~
nailer
Disclosure: I work for [https://certsimple.com](https://certsimple.com), we're
a startup that focuses on making the EV verification process faster and less
painful than other verification methods.

There's a few different reasons people use EV. Most are similar to
verification on other platforms, eg AirBnB, Whatsapp, Facebook (Twitter is
unique as that has additional requirements beying identity verification).

\- You're a smaller company, handing sensitive information, and you want
people to know there's a real legal entity behind the website they're giving
it to. Eg fintech startups and new dating sites.

\- You're a company that has resellers, counterfeiters or other non official
sites and want to distinguish you're the actual brand. Typically fashion
retail is the buggest demand here.

\- You simply want to match a public key to a real world identity, just like
any other cryptosystem, in the same way that the fields in the CSR were
checked in the 90s, prior to GeoTrust inventing DV to save money in the early
2000s. Typical case here is a lot of old school sysadmins who dislike public
keys that haven't actually been proven to be owned by anyone.

\- Phishing.

~~~
Scirra_Tom
Your site looks great, we don't have EV on Construct.net because it's just to
laborious. Will be ordering soon from you.

------
danpalmer
We've found (anecdotally) that our customers care about the "green bar",
although this isn't something we've A/B tested yet.

Note: we're online retail, I don't think it matters for SaaS anywhere near as
much.

------
the-dude
Worked for payment provider : at one point customers did not trust our
checkout page because it was not EV ( it was plain SSL ).

For financial stuff it is apparently expected ( NL ).

~~~
rocqua
How many customers? And how technically apt are they?

I know my grandparents never see the EV certs, because their AV does TLS
termination (I tried to talk my uncle out of it, but he really trusts AV). I
don't see anyone I know caring about an EV cert missing for a payment
provider.

The only exception I can think of would be for big national banks (Rabobank,
ING, etc) for those it might be weird not to see EV because all the others
have it.

~~~
the-dude
It was not mollie.nl, but similar.

~~~
rocqua
I can see that being a weird edge case.

Especially because mollie is often used by smaller sites. The first few times
I saw the name, it felt rather sketchy that I was paying to mollie rather than
whatever business I was buying from.

------
SAI_Peregrinus
The only useful feature of EV certs to me is that they list the company name
in the green box in the address bar. That's handy when first visiting a domain
used by a company that isn't that company's main domain.

------
petraeus
Its more about professional pride than anything else. What I find abut EVs is
the adoption is less based on a projected increase in sales and more on if the
website developer thinks its cool to have.

------
andygambles
There needs to be a mechanism where a site can provide its verified identity
to allow the user to know exactly who they are.

Not every site will need or want this but the ability should exist.

At the moment EV provides this ability. If EV is not seen as the answer then
we need to have something else instead. We could decouple this from HTTPS but
identity is also a valid purpose of signed certificates.

------
mindcrime
_I 'm not a fan of any security mechanism that places a burden on the user_

And as long as people have this attitude, things will never be secure. Users
are already the weakest link and excusing them from having any responsibility
for their own security is not helping.

~~~
Scott_Helme_
I think completely the opposite. The sooner we can stop depending on the user
to behave a certain way so that we can be secure, the better.

We told users for years to look for a padlock and https in the address bar
before entering passwords or credit card details to make sure it was
encrypted. Now we have HSTS so that websites can enforce https without having
to have the user manually check things and risk missing something. HSTS does
not place a burden on the user, we took responsibility from the user and fixed
the issue without having to involve them. That's exactly how we improve
security.

Clicking links in emails is another prime example. We can try to teach the
user as much as we like for as long as we like but ultimately there's almost 8
billion people on Earth, so yeah, good luck on that front! Instead we can
enforce policies like SPF/DKIM/DMARC to ensure the sender is genuine, check
the reputation of domains linked in the body and filter them, scan attachments
for malicious content, prevent execution of scripts, remove administrative
privileges from the user and countless other technical measures we can deploy
without even having to speak to the user once.

Every time we have to ask the user to do something or to not do something, the
technology has failed.

------
andygambles
> One of the things that I wish we had across browsers was a consistent UI so
> we could reliably inform users of the indicators to look for.

The UI was consistent with a green address bar as agreed in the cab forum. It
was Chrome that broke away from this consistency.

------
baby
I've never noticed any difference between a DV and an EV certificate, and I'm
working heavily in this field. The difference is useless unless you actively
look in the address bar to see if there is a difference. Most users won't.

~~~
Scott_Helme_
This is my biggest real concern with EV, we depend 100% on the user for it to
have any value.

I think we learnt that lesson with 'check for https in the address bar' and
now we have HSTS instead.

~~~
baby
> we depend 100% on the user for it to have any value

or on the browser integration. If chrome/firefox decide to remove this
distinction tomorrow, the whole business aspect of it will die.

------
pgl
Pretty thorough examination the pros and cons of Extended Validation SSL
Certificates, with some good discussion in the comments.

------
BrandoElFollito
I hope let's encrypt will support someday EV, without the extended validation.

Yes, without. Because this is supposed to help people, not machines, and
people will never tell the difference. The ones who make the effort to
understand this rainbow of colors around the url bar will not be fooled anyway
(and if they are, the attack was very successful anyway).

All this said, I would like to have the name of my blog next to the green lock
because it looks nice. For free that is.

------
jorgec
Most companies don't care about the EV, aka the GREEN BAR.

For example, Paypal and Apple care but not Google, Amazon or Microsoft. So,
its not a matter of costs but its usability that its practically NIL. Even
Ycombinator is not using it.

As a developer, i am found that practically all customers don't care about the
URL, in fact, most customer don't see the url at all.

~~~
BillinghamJ
The primary benefit I have found is for pinning/CA whitelisting purposes.

All EV certs must have publicly searchable CT records, and go through
reasonably complex validation processes involving some manual human validation
processes, in addition to the usual checks.

This means that:

1\. The barrier to getting an EV cert is higher - and the probability of a
misissuance is lower.

2\. If a misissuance does occur, it should be very easy to find out - by
regularly/automatically searching CT logs.

If you choose two or three CAs whose EV programs you trust, you can pin
against those CAs’ EV roots in your applications (e.g. a mobile app published
by your company).

This is an effective process to reduce the risk of MITMs, and even continues
to work as the CA changes intermediates etc (assuming they have separate roots
for EV).

There isn’t a whole lot of benefit in browsers, unless you have preloaded
pinned certificates there too (which many major sites do).

Also, as an aside, if anyone is looking for EV certs, I have always
wholeheartedly recommended CertSimple. They’re very quick, aren’t too
expensive, and have good support. The certs are issued by DigiCert. We use
them for [https://cuvva.com](https://cuvva.com)

~~~
rocqua
Sure, if I see an EV cert, I trust that cert slightly more. However, unless I
expect an EV cert and happen to check, there is no downside to having a DV
cert.

If you are going to pin your apps to a CA, you have quite a few other options.
For example, you could cross-sign all your certs by your own root CA cert and
pin to that in addition to pinning to the other CA. At this point, you don't
need to trust the CA as long as you trust your own root cert.

~~~
BillinghamJ
I didn’t make any reference to any visual/user benefits/trust from EV certs.

If you’re going to do cross-signing, then you do need to essentially operate
your own root program - assuming you want to keep your own root secure. You’ll
also then presumably need to serve an additional cert (or two, if you’re
keeping your own root offline) in the intermediate chain so it can be
validated by the client.

------
zokier
While some of the criticism against EV might be valid, I don't see many good
alternatives. Should we just collectively abandon any hope for better-than-DV
level of security, is that really a desirable outcome?

~~~
Ajedi32
What kind of alternative are you looking for? DV security is already quite
good, and it's getting better with new measures like Certificate Transparency.

~~~
stephenr
Dv does nothing to tell you who operates the site.

What if someone else had managed to register Apple.co and started using it
nefarioualy? Having an ev cert we can see if a site is actually an Apple Inc
site or not.

There is more to tls/https than encrypting the tunnel.

~~~
Scott_Helme_
Agreed, that's exactly the purpose of EV. The problem is that the user has to
know to look for EV, check it's present and check that it says "Apple Inc."
which is a lot of things to expect of the user! There are also lots of
scenarios that I outlined in my article where you would never see an EV
indicator because of your browser, platform or TLS interception taking place.
Not only do we burden the user but the indicator is also unreliable.

If apple.co was doing nasty things it'd also be blocked pretty quickly with
things like Safe Browsing which is great.

~~~
nailer
A lot of your arguments re: EV are dead on, but they're not to do with the
concept of verifying certificate owners (EV), but rather browser
implementation issues.

Eg, you see an improtant update to a ToS you need to accept or a service you
use will be stopped. You click the link, log in, and your browser says...

For DV:

> This is the first time you've visited this site. The owner has been verified
> as _amazon.com_

or, for EV:

> This is the first tim you've visited this site. The owner has been verified
> as _Apple, Inc._

for a DV phishing cert

> This is the first tim you've visited this site. The owner has been verified
> as _www.google.com-swag.ph_

Unfortunately browsers don't make certificate information available to users,
and are uninterested in whether users understand what they're connecting to
([https://certsimple.com/blog/browser-security-
indicators](https://certsimple.com/blog/browser-security-indicators)).

The same thing applies to mobile Chrome poor identity display compared to
mobile Safari.

This doesn't mean we should stop verifying pubkeys with EV. It means browsers
should improve their UI or let others do so.

~~~
Scott_Helme_
How is the user supposed to know what to verify in the EV indicator though? If
the user is expected to know that the EV indicator should contain "Apple
Inc.", why can't we just expect them to know the address should be apple.com
instead, what's the difference?

I can't seem to get away from two key things that put me off and they are
requiring the user to have some pre-existing knowledge of the name of the
legal entity and then having to manually notice and verify that information on
each page.

Let me list a couple of scenarios to see if I can better articulate my
thoughts.

1) The user wants to buy something from ACME Corp so they search for them on
Google and find acme-corp.com listed as their site. The user visits the site
and sees in the EV indicator that this domain is indeed owned and verified as
ACME Corp [US], the company they wanted to interact with. In this scenario the
user is required to have pre-existing knowledge of who they wish to visit the
site of and then manually verify that information.

2) A user is browsing the web and finds a product on a website that they want
to buy. They check the address bar for https and also notice an EV indicator
that says Bargain Central [UK]. Without existing knowledge of who the company
is, what value does the EV indicator provide?

Maybe I'm missing something, and please do feel free to point out some other
user scenarios, but #1 requires the user to have existing knowledge which is a
pretty big burden to place on them. I can't really think up a scenario these
days where someone would tell you a company name to buy something form or
visit online but not their website address.

With #2 it seems to provide no value because the user has no reference as to
who that company is. Given the information in the EV indicator the user would
need to go and lookup information about the company somewhere else? We
certainly can't assume that they're trustworthy just because they have an EV
cert!

I honestly don't think the biggest problem with EV is browser UI. As I
detailed in the linked article there are many scenarios when EV will never
show because of AV/interception/proxies/etc and there's nothing that can be
done about that. Even if all browsers had a consistent UI, my biggest concerns
would still remain what they are now.

~~~
nailer
> How is the user supposed to know what to verify in the EV indicator though?

In the proposal, the user doesn't know anything about the EV indicator.

The browser simply prominently shows the user the highest level of identity
information on first POST (maybe with a two week delay on fresh browsers).

Do you trust:

\- amazon.com

\- Apple, Inc. (United States)

\- apple.com-yolo.swag.ru

The proposal is particularly neat as it doesn't discriminate against well
known domains with DV, just _shows users what the cert proves at the time they
most need to know_.

I could make this in a day, and prove it improves end user security, if Ryan
(or anyone else) would let me.

(I'll address your scenarios in another comment, just wanted to clarify the
identify-on-first-POST proposal first)

~~~
Scott_Helme_
I'm not opposed to your proposal but I would have some hesitation about an
intersitial like that. The example works well with Amazon and Apple but what
about:

\- some-company.com \- Other Company [United Kingdom] \- some-company.com-
fake.uk

Unless you already know you wanted Other Company [UK] (pre-existing knowledge)
the EV indicator really doesn't help.

~~~
nailer
Thanks. Again there's no explicit EV indicator being proposed in identify-on-
first-POST: just a single UI with the highest amount of info known about the
site's identiy. Re your examples:

1.

> This is the first time you've visited this site. The owner has been verified
> as some-company.com

"OK. Have I heard of these people before? The dash is a bit weird. Not bad,
not good - which is reasonable for site that isn't telling me anything."

2.

> This is the first time you've visited this site. The owner has been verified
> as Other Company [United Kingdom]

"OK cool. I live in the UK and I know who is handling my data."

3.

> This is the first time you've visited this site. The owner has been verified
> as some-company.com-fake.uk

"Euw gross. I'm out of here."

~~~
Scott_Helme_
I totally disagree with #2. What relevance is the country I reside or the
country the company was founded matter? Half of the time companies have
registered addresses all over the world for tax reasons, not to mention things
like franchises, subsidiaries and other legal structures that complicate
things further.

"I know who is handling my data", really? You know their registered name but
nothing about them or who they are, where they are (in the country), are they
big/small, reputable, been established 2 days or 2 years, have 5 staff or 500
staff, nothing. In all honesty, the browser presenting that to me in the
address bar has absolutely no value. It's a simple text string, how can it?

~~~
nailer
> I totally disagree with #2. What relevance is the country I reside or the
> country the company was founded matter?

As you live in the UK, and you noticed business you thought was local or US
based turned out to be from the Philippines or Russia, would you care? It's
essential the country be included.

> You know their registered name

You know more than that, you know the specific legal entity you are dealing
with - the name is part of that, but it's what the name signifies. It's
accountability, exactly like every other verification platform: Instagram,
Facebook, whatsapp, GPG + university directory with keys, GPG keybase. Oddly
enough the verification process for verifying individuals on these platforms
is almost identical to EV's.

The only place we trust random pubkeys and a network address is the web, and
that's because GeoTrust wanted to save money in the early 2000s.

> are they big/small, reputable, been established 2 days or 2 years, have 5
> staff or 500 staff

You are confusing identification with approval. See: every platform listed
above (except Twitter, which does actually confuse them and in currently in a
heap of turmoil over it). Also your passport - it doesn't mean you're a good
person, it just means we know which person you are.

~~~
Scott_Helme_
> As you live in the UK, and you noticed business you thought was local or US
> based turned out to be from the Philippines or Russia, would you care? It's
> essential the country be included.

If I "thought" it was local or if I "knew" it was local. The information is
only useful if I knew it was local (prior knowledge) and EV UI tells me it's
not (and I notice, and then act accordingly).

> You know more than that, you know the specific legal entity you are dealing
> with - the name is part of that

No, I really just know the name, because that's all that's in the EV UI unless
I go digging...

> it just means we know which person you are.

And a DV certificate tells you which website I am, scotthelme.co.uk, which is
what you typed into the address bar.

------
enord
Top 10 sites are not using EV because they don't wan't to meet the
expectations of EV-level trust.

If twitter compromises your account details, you can change your passwords. If
your (E-validated) electronic banking service compromises your account
details, you can sue.

EV is laborious for social reasons (and some technical reasons ofcourse,
nobody likes ASN1 extensions etc.), your effort to secure and validate a
service is proportional to your stake in the transaction.

~~~
pfg
I'm not sure I follow, why does a site's use of Extended Validation affect
your ability to sue them? Or do you mean it's a psychological thing - "If our
site uses EV, we're more likely to get sued"?

~~~
enord
Well it's expected in contexts where legal responsibilities are defined and
widely understood (or misunderstood, depending) and also because it's
literally the reason they exist.

To quote wikipedia: >An Extended Validation Certificate (EV) is a certificate
used for HTTPS websites and software that proves the legal entity controlling
the website or software package.

~~~
pfg
I still don't quite follow. You were talking about adoption among top 10 sites
- is your argument that Twitter is not using an EV certificate[1] because a
judge might say something along the lines of "That's all great but how do I
know this twitter dot com thing is actually a site operated by Twitter, Inc?
They're not using EV!" if some users sues them over a data breach?

[1]: Not really important for this discussion, but slightly relevant: For some
reason Twitter uses both EV and non-EV certificates depending on geolocation.

~~~
enord
To adress your aside: If twitter uses EV somewhere end non-EV elsewhere
(depending on geolocation) then I'd wager they do it to comply minimally to
the juridistiction in which they serve requests, that is: minimise legal
exposure by foregoing EV-certs where this is legally tenable.

ps: I'm getting some downvotes for my view on this, but little in the way of
arguments. I'm happy to be corrected. Am I coming off as an asshat on this?

~~~
pfg
Without getting into whether I agree with this or whether there's any data
supporting such a statement, I think you could make the argument that the EV
indicator might make users feel like there's a legal entity behind a site that
they could go after, compared to sites without EV indicators.

I don't think you can make the argument that businesses don't adopt EV because
that'd expose them to legal risk. That's just doesn't fit into my
understanding of how the law and courts work. I'm not aware of any evidence or
precedence that would support this, and the EV guidelines don't mention
anything of this nature either.

~~~
Scott_Helme_
Something that I see a lot in the discussions around EV is "the EV indicator
might make users feel" x, y or z.

Not to sound too harsh but I don't care about making the user 'feel' anything.
I want to make them more secure.

