
Extended Validation Certificates Are Dead - jcurbo
https://www.troyhunt.com/extended-validation-certificates-are-dead/
======
technion
I'm seeing a lot of discussions about financial and specifically banking sites
here. For the average user, there's no reason or need to phish a particular
financial site.

One of our engagements sent users to a site we just made up, and asked for
user credentials for a site they had never heard of in order to access cat
videos. In most cases, we were given valid domain credentials. I'd bet money a
high percentage of those were also banking credentials. What good would an EV
cert at the bank do for this?

~~~
throwawaymath
It wouldn't do anything, because users don't check it. I used to be involved
in phishing campaigns against internal employees at a fintech company. Despite
these employees being highly technical people, I can't recall incorrect or
missing extended validation certificates ever stopping them from submitting
credentials.

As another commenter has said, I can't personally tell you the name of any
specific website with an EV certificate. I don't know any friends or family
who actually check for the presence of correct EV certificates. It's a cool
idea and it's made CAs plenty of money, but it's just too subtle of a cue.

I think many people are resistant to the idea that extended validation
certificates aren't effective for one or both of two reasons. First, they
probably want to actually do something instead of being hopeless, so they
consider doing something better than nothing even if it's not ideal. Second,
they are reviewing the technical specification and finding it sound, but not
grounding it in the reality of how users work.

Part of the argument against them is not just that they're ineffective, but
also expensive. It's not unreasonable to simply call it snake oil. The visual
cue would need to be significantly more prominent - up to par with the red
versus green icons of HTTP and HTTPS, respectively - in order to have a real
impact. Users would need to have better training and education to come to
_expect_ the extended validation instead of merely feeling more assurance when
it's present. The system has insufficient penalty for sites which should have
extended validation but only present domain validation, and browser-buyin to
the concept is fading.

~~~
wbond
> First, they probably want to actually do something instead of being
> hopeless, so they consider doing something better than nothing even if it's
> not ideal.

Right, once OV and EV certificates are effectively removed from browsers,
users such as myself will no longer have _any_ tool to help ensure we are
interacting with the entity intend to be interacting with. It is kind of like
getting a cold call from your credit card company saying their has been
suspicious activity and they want me to authenticate my account with personal
details. I always call the phone number on the back of my physical credit card
to ensure someone isn't scamming me.

Rather than removing EV certificates as a concept, I would love to see some
experiments run by browser vendors to see how users can more readily
understand who they are interacting with. But instead, the solution seems to
be to get rid of the only option since it doesn't work in its current
incarnation.

> Part of the argument against them is not just that they're ineffective, but
> also expensive. It's not unreasonable to simply call it snake oil.

I have a hard time understanding this argument. You can purchase an EV cert
for $80 a year from NameCheap. The extra cost is because they have people
verify that the company details you have provided are valid and that you are
an authorized representative of the company. Any company that is more than a
solo founder is going to be in dire straights if $80 a year is too much. I
mean, are you even going to find a domain name and hosting for less than $80 a
year?

In reality though, I don't think much of anyone other than major email
providers and financial institutions really need to worry about EV. If a
website doesn't have EV, but uses PayPal, I have no qualms. But if I go to
long into Fidelity or PayPal and they couldn't be bothered to spent $100 per
year to help me ensure I am actually interacting with them, that says a lot to
me. I mean, even my small town NH bank has an EV cert. It just makes sense if
you are dealing with finances.

~~~
technion
OV was never really accessible in browsers. Even the vendors pushing these
seemed to avoid showing how to identify one (when they would screencap the EV
green bar), and probably for good reasons.

> You can purchase an EV cert for $80 a year from NameCheap

I've been through this a quite few times. The cost of the cert isn't the true
cost. If I could pay $80 to Lets Encrypt to have every issued cert be EV, I'd
do it just to avoid this bikeshed. Every single time I've done it, the
validation process has been extremely painful. I feel like it's made up on the
spot by whatever offshore person gets asked to do the validation. Documents
accepted last year are suddenly not accepted at renewal time. Being denied
because my Australian company doesn't show up on a UK business register for
example.

~~~
donmcronald
> avoid showing how to identify one

The certificate policy identifier will be 2.23.140.1.2.2 for OV. You have to
look at the certificate details to find it.

I looked into it for someone once. Then I watched in amazement as less
technical person insisted on OV certificates.

------
tgsovlerkhgsel
EV is very useful when banks decide to host some parts of their online
presence on what sounds like a phishing domain. Think "onlinewebconnect.com",
which redirects through "live.logonvalidation.net" (Saxo Bank - they're hip
enough to have their own TLD but apparently not smart enough to actually use
it for something good) or the various domains banks liked to use for their "3D
secure" login process.

It also drives the cost of phishing attacks up significantly. Sure, you can
get a confusing cert issued, but if it requires you to _create a new company_
, it's not going to be used in mass phishing attacks.

~~~
throwawaymath
Extended validation _isn 't_ very useful, for exactly the reasons the article
explained. Most users don't take advantage of its benefits no matter how
technically sound the concept is. Providing users with anti-phishing and
phishing-detection tools doesn't mitigate phishing. The way to mitigate
phishing isn't to empower the user with sophisticated awareness, it's to
eliminate the need for that awareness.

~~~
themihai
Ok so we just removed the "sophisticated awareness" and now we wait for a
fantasy/unknown solution. No brainer, right? To me this looks like a bad day
for the open internet and a good day for walled gardens(i.e. Apple Store).

~~~
throwawaymath
How exactly did you get from the inefficacy of extended validation
certificates (and their subsequent obsolescence) to solidfying moats for
walled gardens?

~~~
snowwrestler
The original purpose of an EV cert is to provide a browser UI that tells a
first-time visitor that they can trust the website they've landed on. This is
a separate goal from TLS in general, which is just supposed to secure the
traffic in transit.

Google in particular has no interest in providing such a browser UI. They want
users to use Google Search to establish trust instead. "If you're not sure,
Google the business name" is common advice to avoid copycat sites. Boy is that
a good position for Google to be in! Why would they invest in an alternate
solution with a distributed architecture and client-side UI?

Almost all the "best practice" security advice today is centered around
protecting existing relationships with sites. "Use a strong password, a
password manager, and two-factor-authentication" does nothing to protect a
first-time site visitor from a scams. It makes sense for security
professionals to focus on the lowest hanging fruit, but the result is web in
which first time site visits are perilous and uses get no help at all with
that.

~~~
throwawaymath
Yikes there's a lot of (in my opinion) misconceived cynicism here...

 _> The original purpose of an EV cert is to provide a browser UI that tells a
first-time visitor that they can trust the website they've landed on. This is
a separate goal from TLS in general, which is just supposed to secure the
traffic in transit._

This isn't _really_ accurate. Basic TLS (domain validation) provides
encryption _and_ authentication - if TLS did not provide authentication in its
most basic form, the encryption would not be very secure on its own. Extended
validation merely adds further parameters (properties, characteristics, etc)
to the server side of the authentication process that already exists in TLS,
in combination with administrative work on the part of the certificate
authorities.

Then the client provides the UI visual indicators corresponding to the
authenticated identity, as you say. But while all of this technically works,
_most users don 't bother with checking it._ Security with friction to use
doesn't typically provide any security, it just makes you feel like you're
doing _something._

 _> Google in particular has no interest in providing such a browser UI. They
want users to use Google Search to establish trust instead. "If you're not
sure, Google the business name" is common advice to avoid copycat sites. Boy
is that a good position for Google to be in! Why would they invest in an
alternate solution with a distributed architecture and client-side UI?_

I can trade your flavor of cynicism with my own: certificate authorities don't
want TLS certificates to be cheap, so they come up with shiny options such as
OV and EV to have something they can upsell.

See what I just did? We can just keep arguing cynically if we'd like, but we
don't arrive at any new insight about the actual point. The fact of the matter
is that it's largely irrelevant what Google's motivation is, because the
efficacy of extended validation (or lack thereof) does not rely on Google (or
any other browser's) motivation. And for what it's worth, Google is not the
only browser maintainer moving away from EV visual indicators.

 _> Almost all the "best practice" security advice today is centered around
protecting existing relationships with sites. "Use a strong password, a
password manager, and two-factor-authentication" does nothing to protect a
first-time site visitor from a scams._

This is a fair point. It's definitely true that phishing is not as sexy a
problem as "technical" security vulnerabilities, and so gets relatively less
attention. But a security mechanism only augments security if it's actually
used or adhered to. I'm not debating the technical merits of extended
validation. I'm stating that it's ineffective beause it's a technical solution
to a social problem. The way to resolve that social problem is through more
sophisticated education and training. Or more likely, to re-architect the
interface and browsing methodology in a way that obviates phishing entirely.
Just because one of those approaches seems out of reach doesn't mean we should
settle for EV, which in practice doesn't do anything. The only nontrivial
users of EV are banks and financial institutions; these are the same
institutions who have completely bought into security questions, inability to
paste passwords and draconian password complexity requirements.

~~~
snowwrestler
TLS authenticates in a technical sense. The purpose of EV was to tie the
technical authentication to existing processes for legal authentication.
That's why, for example, EV certs must include the legal name of the company
or a registered DBA (note--edited to fix this).

> But while all of this technically works, most users don't bother with
> checking it.

Shouldn't that be a UI problem? But instead of improving the usability and
utility of EV and OV cert content, browsers are instead just hiding it.

> I can trade your flavor of cynicism with my own: certificate authorities
> don't want TLS certificates to be cheap, so they come up with shiny options
> such as OV and EV to have something they can upsell.

A lot of people do feel this way. The objection to OV and EV certs has a large
cultural component. Browser providers don't like CAs in general. Part of it is
because most CAs are not as technically savvy. But yes, part of it is: who is
going own identity and authentication on the Web? It's a tug of war with real
business implications.

What gets lost in the fight is that EV and OV certs are not just stupid scam
upsells. Conceptually they are different from DV certs, and contain different
content that could be used to solve real problems for users. Sure--anyone can
create a company and register it with a CA to generate an EV cert. But doing
so leaves a paper trail that is easier for law enforcement to follow than just
a DNS entry for a DV cert.

> The way to resolve that social problem is through more sophisticated
> education and training.

This is not how social problems get solved. We didn't provide sophisticated
education and training to help people discern real clothing stores from
criminals who will rob you; we used the collective resources of society to
create processes and records that help us hold business owners accountable if
they use their business to commit crimes.

~~~
tialaramex
Suppose Alice is looking at a web page,
[https://example.com/](https://example.com/) which she believes is run by Bob,
and Alice types in her credit card number, and then she presses the Charge
button and a form submission happens, which means behind the scenes the
browser does HTTPS POST to
[https://card.example.com/](https://card.example.com/) Let's walk through
this:

1\. Alice's browser looks up card.example.com and gets some IP address, it
connects to this IP address, with TCP, on port 443 the standard HTTPS port.

2\. It does a TLS handshake with the server that answers, it sends SNI asking
for card.example.com, the server sends a certificate and proof that it owns
this certificate (in older setups the proof may be implied but let's not worry
about this detail)

3\. The browser validates that the proof is correct, that the certificate is
acceptable (signatures etcetera) and that the certificate has a Subject
Alternative Name matching card.example.com, if anything is wrong it aborts.

4\. Otherwise the browser writes the HTTP POST data over the TLS connection to
card.example.com, it gets back an HTTP response body, which it processes as
normal, for example, the display body may be a 30x series HTTP redirect back
to [https://example.com/](https://example.com/) and that's displayed for
Alice.

Now, where in this process did Alice get a chance to verify that her credit
card data goes to Bob?

Nowhere. Even if card.example.com has an EV certificate which says the
subject's real name was "Bob Limited" that information is meaningless to a web
browser and is never displayed for Alice to look at.

Let's suppose we really try hard to help Alice here. When do we show her the
"Bob Limited" subject? We only discover it during the HTTPS POST operation,
milliseconds before we send her credit card data. Do we... stall everything,
and hope Alice can examine the certificate while the transaction waits? Good
luck with that, even if Alice is (unlike all normal users) fastidious enough
to not just click "Yes, yes, go away and stop bothering me you stupid
computer".

~~~
snowwrestler
The EV cert is served with example.com, where Alice can see it.

EV is not necessary for card.example.com because a) it's not a domain that
Alice will visit directly, and b) Bob has out-of-band opportunities to confirm
that he wants his application to connect to card.example.com.

EV does not provide better technical security than DV, it provides better
information for following up on problems. If Alice thinks Bob ripped her off,
she can look at the EV cert on example.com to get the legal name of Bob's
business and the locality in which it is incorporated, and file a complaint
against him. She doesn't need to know about how Bob processes credit cards to
do that.

~~~
tialaramex
But why bake this stuff into the certificate in this scenario?

If Alice is only going to check any of this long afterwards it doesn't need to
be part of the X.509 certificates issued for the Web PKI, Alice can check in
any number of ways which business it is that she thinks ripped her off.

Of course since she waited until after she was ripped off it may be that it's
a company with no practical presence in her country and she can't do anything
about it anyway. But EV doesn't make any difference there.

------
ggm
They were pretty silly in the first place. All it did was emphasise what a
giant scam the CA business is: either all certificates have undergone
meaningful validation, or none have, having higher and lower grades is ..
broken.

~~~
snowwrestler
The purpose of an EV cert was to provide the user with trust that the company
running the site is a legitimate business. That is different from the purpose
of TLS in general, which is simply to secure traffic over the wire. That's why
they are different products.

The use case for EV is hard, and CAs did not always deliver on the goal. But
instead of working on that hard problem of trust on first visit, most security
professionals have decided to ignore that problem and pretend that all certs
have ever needed to do is secure the wire. Of course EV certs look silly under
that line of thinking, but that doesn't mean it's right or complete.

The industry has basically given up on the idea that there is some way to
establish trust on first visit. Which is nuts, because we take it for granted
in real life that we can just walk into a brick and mortar store and conduct
business without getting mugged.

~~~
ubernostrum
_most security professionals have decided to ignore that problem and pretend
that all certs have ever needed to do is secure the wire_

If you want to blame someone, blame the original designers of the current
system, who decided certificates had to be a one-size-fits-all solution for
_both_ encryption and identity. Also, blame the years and years and years
during which people on sites like HN condescendingly insisted that identity
was the important part of TLS/SSL, and who more or less said you'd be better
off unencrypted than encrypted without ultra-mega-hyper-octuple-verified
identity.

 _The industry has basically given up on the idea that there is some way to
establish trust on first visit. Which is nuts, because we take it for granted
in real life that we can just walk into a brick and mortar store and conduct
business without getting mugged._

In real life it's difficult and expensive for me to rent a brick-and-mortar
storefront, cover it with the branding and logos of a trusted company, stock
it with real-looking products and employees in uniforms, etc. On the web, it
takes five minutes and costs little or no money to produce a good-enough
imitation of a trusted company's site. Any attempt to analogize between them
will fail because of how much lower the barrier is online. Any attempt to say
that it's easy in real life, so it ought to be easy online is based on missing
this fundamental fact.

Also, we live in an age where it's profitable to cold-call people on the phone
and say "I'm the tax authority and you owe money, buy $500 worth of iTunes
gift cards and send them to this address", and where the majority of calls
that come to my phone use spoofed caller ID to try to scam me.

"Trust on first visit" is really a monstrously hard problem, and I think
you're underestimating that.

~~~
snowwrestler
I'm not underestimating how hard the problem is, I'm complaining that people
are taking the difficulty as an excuse to pretend it does not exist, or to
treat it as unsolvable.

I'm not saying it's easy in real life, I'm saying it's largely solved in real
life. There is a big difference between those two ideas.

The difficulty was part of how it was solved. In addition to the physical
difficulty of setting up a store, businesses have to be registered and
licensed by state and local authorities. The purpose of the EV cert (and the
OV cert, really) was to tie web trust back to that same regulatory
infrastructure. If you have a problem with a site using an EV cert, you can
look up the company info in the cert and contact their local authorities.

~~~
ubernostrum
_The purpose of the EV cert (and the OV cert, really) was to tie web trust
back to that same regulatory infrastructure._

Except the only way to get what you want using EV is to force literally every
site on the internet to go through the EV cert process. Otherwise, somebody's
going to go get a "less verified" cert, set up an impostor site and phish
people.

Is that really the world you want? Is that the price you're willing to pay to
get it?

~~~
snowwrestler
> Except the only way to get what you want using EV is to force literally
> every site on the internet to go through the EV cert process.

No it's not. There are a lot of ways to physically sell things without setting
up a retail establishment. You can drag a box out onto the sidewalk and sell
sunglasses to people; you can host a yard sale, you can set up at a flea
market, you use a classified ad or Craigslist, you can sell through MLM, etc.
Customers will calibrate their level of trust based on the experience you
provide.

Operating a physical retail store (or a bank branch, or a restaurant, etc)
carries with it an implicit promise of trust to the customer, and it's a
promise that is backed by social and legal conventions.

So there's a range of experiences and implied trust in physical life, and it's
fine if there is a range online. Site operators could choose the level of
trust they're willing to invest in providing.

> Otherwise, somebody's going to go get a "less verified" cert, set up an
> impostor site and phish people.

That's only true if browsers make less verified certs look the same as more
verified certs, which is what they are doing. It's a self-fulfilling prophecy.
Now every site looks like a guy with a box on the sidewalk.

~~~
ubernostrum
_That 's only true if browsers make less verified certs look the same as more
verified certs_

Given that decades of user research overwhelmingly indicates that the average
web user does not understand the components of the browser URL bar, and in
many cases those users are completely unaware there even _is_ useful
information there, I'm going to bow out of this, because you're now into
territory where you need to forcibly educate every single person on earth to
understand the URL bar.

(and you're "only" now requiring that every single person who will ever do
business of any sort must pay up for an EV cert, but that's actually less of a
problem than trying to force people to understand what an EV cert is and how
to tell if a site has one)

~~~
snowwrestler
Why are we constrained to the URL bar?

I think people have just developed a weird blindness about the possibilities
of user interface in browsers. There's no reason browsers could not have
created all sorts of interesting user experiences with the validated business
information in EV and OV certs.

------
linsomniac
Another way to look at this article is: The browsers are killing EV certs.

That seems to be the bulk of the point he's making, EV certs are dead because,
especially on Mobile, you can't even tell they are there. He doesn't really,
in my mind, support the case that EV certs never were worth anything. I
definitely liked to see them when I went to my banks and the like. But I'll
admit that I don't remember which ones had them and which didn't, other than
that I expected my financial institutions to have them.

~~~
WorldMaker
> But I'll admit that I don't remember which ones had them and which didn't,
> other than that I expected my financial institutions to have them.

This is a core point in the article too that you've glossed over: no _one_
knows which websites must have EV information other than a general "hope my
bank has one". EV certificates are useless not just because the browsers are
dropping them, the browsers are dropping marks for EV certificates because
they are useless for actual security.

They were an interesting attempt at security, but like the "take your shoes
off at the airport", it only really helped you from maybe blowing up your own
foot, tops. Ultimately the only thing that EV certificates were doing was
lining the pockets of security theater predators, because despite "reports"
they've never really meant anything to the average consumer and most consumers
never learned how/where to look for them except sometimes "maybe my bank
should have one, I don't know?"

~~~
l9k
This is worse than that, because no one ever wondered if they should have one.

People only notice when it is there.

------
RcouF1uZ4gsC
I may be different, but to me it seems that EV certificates are useful for
dealing with domain typo fishing. Google.com is pretty short and memorable.
However, when I type my bank's address, especially if it is a small bank,
seeing the EV certificate gives my more confidence that I did not make a typo
in the URL. Given that LetsEncrypt makes if free and painless to set up https
if you have control of a domain, the EV certificate just gives me just a
little bit more comfort over a DV especially for sensitive information.

~~~
gruez
>seeing the EV certificate gives my more confidence that I did not make a typo
in the URL

not really. there's nothing preventing an attacker from creating a legal
entity with the same name and legitimately getting a EV certificate.

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

~~~
ocdtrekkie
This is a much easier problem to deal with than trying to make any other
strategy useful. The requirements to get an EV certificate can and should be
updated, but it's the closest thing HTTPS does to being a useful security
measure.

The reality is that good security doesn't scale. If an entity starts
specifying a reasonable list of certificates it has directly verified are the
trustworthy well-known entities people expect, you have a good trust system.
Once you start throwing in an automatically-verifiable system where everyone
should be able to participate, phishing is going to happen.

As much as Let's Encrypt helped encrypt the web for free, it also guaranteed
that convincingly phishing the web is also free. Making a legal entity and
going through the EV process is a level of frustration that isn't easy to
handle repeatedly, and very few checks would be needed to be added to EV to
make it near impossible for an entity to rebrand and reappear after being
banned for misusing it's certificate. Notice that stripe.ian.sh doesn't
actually have an EV cert anymore: A system working as designed.

The only way we are going to ever ensure your bank site can't be imitated by
some kid in their garage is going to be to create a system that a kid in their
garage can't participate in. And the closest thing to that is EV.

~~~
owenmarshall
> Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system
> working as designed.

Comodo has apologized for incorrectly revoking the certificate for
stripe.ian.sh and offered a new EV cert.

[https://www.comodoca.com/en-us/about/blog/on-comodo-
ca’s-rec...](https://www.comodoca.com/en-us/about/blog/on-comodo-ca’s-recent-
revocation-of-an-ssl-certifi/)

In fact, many browser security developers would disagree with your assessment:

[https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...](https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/NjMmyA6MxN0)

~~~
ocdtrekkie
I have very little faith in the opinions of "browser security developers" at
the moment on account of browser security being a joke. Their focus has been
on technical security but lacks practical security. Yes, stripe.ian.sh exists,
but have you ever seen a truly malicious use of EV?

Browser security developers concern themselves with arcane exploits of
sandboxes while they don't mind nearly that every browser extension has full
read/write access to everything people see and do.

EV has flaws, but it's better than literally anything else. We shouldn't be
promoting HTTPS if it isn't solving this, the other problems it attempts to
solve are mostly overstated problems. Because phishing is a vastly bigger
threat than MITM.

EV has theoretical flaws but solves real problems, HTTPS without it has real
problems and largely solves theoretical flaws.

~~~
kelnos
> _but have you ever seen a truly malicious use of EV?_

Assuming there hasn't been, I think this just supports the idea that EV certs
aren't useful: the bad guys don't even feel the need to try to use them
maliciously!

~~~
ocdtrekkie
Or the return isn't worth it. Malicious actors have to assume that any given
domain, certificate, URL, etc. will get blocked or shut down by the security
industry, so being able to cycle those endpoints is key. EV is not easy to
automate/cycle, and can also be more cost prohibitive, so each cycle is less
profitable as well.

That's my point: Systems that don't scale are less profitable to attempt to
abuse for malicious ends, because more time and effort has to be invested into
any given effort, and ideally, there are actual humans involved in the process
which catch discrepancies.

The other reason you may not see a lot of attempts to find exploits in EV
(apart from Ian) is that most of the actors sites want to pretend to be aren't
using EV either. If you want to fake yourself as Google, EV isn't going to
help you since Google doesn't use it.

I would argue the claim "bad actors aren't trying to abuse it so it isn't
effective" to be silly, as that claim would apply among all methods that bad
actors can't meaningfully abuse.

------
niftich
It's got more credence coming out of Troy's mouth than, say, a random
commenter's like mine, his somewhat bit too scathing snark notwithstanding,
but on the "stripe.ian.sh" thread a few months ago I observed [1] that EV, or
rather, people's mental model of the trust that EV confers is broken. People
typically care about whether the site they arrived at was the one they were
intending to visit, which the computer can't possibly know without additional
input, but EV has attained a role of serving as a flawed signal of such,
because the browser bar said something that doesn't look alarmingly different.

What we're seeing now is the convergence of forces that are pushing short-
lived, automatic DV certs and players who are keen on de-emphasizing EV's
imperfect role as a destination surety signal.

Big sites can get by with DV because people trust big sites by fiat, just by
mental associations they already have to a URL. There's no benefit to Facebook
having an EV cert, because literally everyone who'd want to visit Facebook
knows Facebook's URL. User error about entering credentials on the wrong site
-- accidentally due to typosquatting, or through leading such as phishing --
is better mitigated in other ways: multi-factor authentication (especially
unproxiable such as U2F); not by making the high-profile site pay thousands of
dollars for a text string in green, when there's users who fall victim to
phishing from bizarre domains too.

[1]
[https://news.ycombinator.com/item?id=15904513#15909273](https://news.ycombinator.com/item?id=15904513#15909273)

~~~
CaptainZapp
_It 's got more credence coming out of Troy's mouth than, say, a random
commenter's like mine, his somewhat bit too scathing snark notwithstanding_

If a CA flogs a guarantee for very expensive certs, but fails to explain what
it entails. Then bloviates about nerds on the twitter account of the CEO to
then block Troy (who, once again, asked a super legitimate question) then they
not only deserve all the snark slung into their general direction.

No, they deserve to fucking die!

------
themihai
I actually found EV useful especially when logging in financial websites. Of
course most people can't make the difference between http and https but I
thought this issue will only be fixed by time.

~~~
Ixio
That's actually how I found out my Lenovo was doing MITM a few days before the
whole Superfish debacle exploded on the net. I went on Bitbucket (I think) and
noticed something seemed different, I realised it wasn't showing an EV
certificate: I dug deeper and saw that the issuer was suspect.

I feel that EV certificates do have their use for high-worth targets (banks
and so one). Getting one is not trivial and definitely not scalable. Maybe
they are a bit overpriced, maybe the certificate industry is kind of sketchy,
but that's other debates.

------
Buge
I get that it's unreasonable to expect users to distinguish EV from DV certs.

But a machine should be able to distinguish. There should be an Expect-EV pin
header, just like HSTS and Expect-CT. That way you can be sure the certificate
wasn't issued via DNS hijacking.

~~~
ubernostrum
The root problem is SSL/TLS was largely promoted, for years and years, as
conflating two concerns:

1\. Can an arbitrary third party eavesdrop on my communications?

2\. Am I communicating with who I think I'm communicating with?

It is now extremely easy to handle use case (1). Use case (2) is still
genuinely hard, because even extremely technically literate security-savvy
people can still easily be phished (my current go-to example is this talk:
[https://www.youtube.com/watch?v=ZjW12K0IHgo](https://www.youtube.com/watch?v=ZjW12K0IHgo)).

Compounding the problem, many people insisted, for many years, that use case
(2) was the overwhelming majority of all the value of SSL/TLS, and use case
(1) was at best a tiny microscopic fraction of a fraction of a fraction of
what was useful about SSL/TLS.

Lest you think I'm exaggerating: I've spent years arguing with people,
including right here on HN, about this, and being condescendingly told that
identity verification is the crown jewel, and that if I'm not going to make
use of that then I might as well literally just go back to plain unencrypted
HTTPS, because apparently that's actually better than using SSL/TLS without
identity verification.

Also, I really recommend watching that video I linked. It's a security
engineer at Stripe, talking about how she ran some pretty successful campaigns
within the company. Whatever you may think of them, they're not unlettered
philistines. But even things like your "Expect-EV" wouldn't have helped -- she
cites an example of people noticing their password manager wasn't autofilling,
because it knew they weren't on the expected domain, and then _users manually
copy /pasting the credentials out of their password manager anyway_. There
just aren't any easy "just do X" technical solutions here.

~~~
tzs
> she cites an example of people noticing their password manager wasn't
> autofilling, because it knew they weren't on the expected domain, and then
> users manually copy/pasting the credentials out of their password manager
> anyway

One big reason people do that is because probably 99+% of the time their
password manager fails to fill the fields is not because it is the wrong site.

It is almost always because the site has done something with its fields that
is either preventing the password manager from finding the fields, or is
blocking it from filling them (often intentionally).

~~~
ubernostrum
_Why_ people bypass the password manager's domain checks isn't relevant.

The issue is that credential stores which know how to recognize the "real"
version of a site aren't going to achieve the level of effectiveness we'd like
to have against phishing.

------
cm2187
I actually kind of agree that EV certificate inspire more confidence when
buying something on a dodgy website that you never heard about. But for that
one needs to be tech savvy enough to even recognize what an EV certificate is
and how it is different from a DV cert, and I am sure that even most
developers aren't sure exactly, let alone the wider population. So I doubt it
gives much benefit to any website.

~~~
snowwrestler
If only there was some common, easily visible browser UI element that told
users when an EV cert was present, so they didn't have to understand the
differences between certs.

------
zwetan
next: code signing certificates under Windows

a lot of B.S. there too

~~~
_nalply
Yes. Two years ago I bought EV for code signing to avoid Microsoft
Smartscreen.

The whole experience left a stale impression: we were then in the process of
switching to non-profit and already dissolved the for-profit company but got
the EV for the old company anyway! Clearly the CAs have a moral hazard: if
they check too thoroughly they will sell less certificates, so it is not in
their interest. In my case they blatantly asked me to provide bullshit
evidence for the dissolved company!

No wonder that Microsoft Smartscreen doesn't seem to treat EV certificates as
all encompassing truth of existence of something. We had to jump through some
more hoops to satisfy Smartscreen, the certificate alone was not enough.

------
BillinghamJ
EV certs are a useful as a barrier-to-entry when you do cert pinning against
roots/intermediates.

~~~
dagenix
Except that HPKP is being deprecated by Chrome
([https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink-
dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn)). And I'd suspect other browsers will follow.

~~~
sandij
When pinning CAs instead of certificates, you’d use CAA instead of HPKP.

~~~
toast0
CAA isn't restricting acceptance of certs, it's restricting issuance, assuming
the attempted issuer is compliant, competent, and that your domain didn't get
hijacked.

------
jiveturkey
no need to RTFA! EV certs were nonsense from the start.

------
wbond
Google seems intent on creating a more confusing UX in regards to EV certs as
EV looks more similar to Non Secure than secure sites in Chrome 69.

For now this has given me the impetus to ditch Chrome. All of the other major
desktop browsers still provide useful UI for EV certs. I’m less inclined to
deal with finances on mobile through a website anyway, as every financial org
I’ve had to deal with has an app, and Apple ends up being the gatekeeper in
that realm.

Hopefully there will be some sort of push for useful additions to certificate
security coming out of Google, as right now they seem more determined to just
be undermining things.

~~~
tptacek
That is an interesting way to describe the most effective mover in all of TLS
security. No company has done more to improve it. We owe to Google, in at
least a substantial way, if not always entirely:

* The dis-trusting of basically every skeezy dis-trusted CA.

* The adoption of TLS 1.3.

* Certificate pinning.

* HSTS preloading.

* The modernization of OpenSSL.

* The Heartbleed attack that prompted the modernization of OpenSSL.

* Certificate transparency.

I'm rattling these off my head and certainly forgetting something. Obviously,
if you broaden the question to _everything_ relevant to browser security, the
list gets much longer.

~~~
tialaramex
I'm definitely not giving you "dis-trusting of basically every skeezy dis-
trusted CA" for Google.

All the heavy lifting continues to be done by m.d.s.policy, which is
Mozilla's, not Google's if it's anybody's. I used to want to believe that the
(behind closed doors) other root programmes also had their own effective
mechanisms. A few years of working with m.d.s.policy and watching absolutely
nothing else making any difference disabused me of this notion. It gets done
in public or it doesn't get done at all, and m.d.s.policy is where it gets
done in public.

Does Google have (mostly in the form of Ryan Sleevi who is a Google employee)
a contribution to m.d.s.policy? Sure they do. But there are quietly also
people from Microsoft and others paying attention, it's just that Ryan is much
noisier, for good or bad.

If I was going to single out a _person_ for this work it would be the late
Gervase Markham, who was a Mozilla employee. The big list of problems at
StartCom is Gerv's list, for example. I think even the idea to go after
auditors not just CAs was Gerv's idea.

~~~
tptacek
I'm really not interested in whatever weird personal problems you might have
with Ryan Sleevi, sorry.

