Are EV certificates worth the paper they're written on? | Hacker News Reader

Are EV certificates worth the paper they're written on?

scotthelme.co.uk

88 pointspgl66 comments

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.

I do touch on that point in the article but the numbers show that larger sites are more likely to use EV and smaller sites are less likely to use it. The figures seem to go against the logical assumption. I grabbed the figures and published them because I thought as you do.

Disclosure: I work for 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.

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

> It’s the lesser-known sites, I think, where this sort of “trust” (for some version of trust) matters more

I think this also goes by the 'nobody got fired for buying IBM rule'.

For the nominal cost of the EV you don't want to take a chance that you are wrong. It can't hurt and it might help.

Additionally I bought one also because I kind of like the green at the top and I think that as a design element it adds to a page in the position that it's at.

I don't know anyone who would say "oh this ecommerce website must be legit because it has its name next to the green lock"

May be true from a user's perspective, but EV could still be useful to ward off phishing.

Amazon may do it because others are doing it and as you say they don't have to because they are already trusted and at the top of the heap. And further they don't want to empower other sites as being legit by featuring a design element (the green at the top) that others can easily copy.

An example of this?

Let's say back in the day you were the market leader and had "intel inside" (the processor). But you didn't use the 'intel inside' logo because then others could have the same sticker and the public would think 'oh ok it's the same stuff in brand X'.

Manufacturers frequently come up with different names for product features for a similar reason.

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.

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

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.

It was not mollie.nl, but similar.

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.

There is a huge presence of EV on financial sites where it is used considerably more than in any other sector. I never did come across a reasonable explanation for that though, I'd be interested to know why.

I got the impression this customer did not trust our SSL because all Dutch banks use EV, and she was going to do a 'bank transaction'.

Specifically iDeal, which is implemented by the banks. But our checkout proces was one step before this.

So maybe it is a network effect within financials?

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

In April next year we will have the CT requirement for all certificates so EV will lose an edge there.

For the pinning in a mobile app, would you still depend on the PKI or not just pin against your own private CA/certificates?

Our mobile apps use the same endpoints/hostnames as our public API, so fairly important for it to be publicly trusted.

I do still think the barrier to entry aspect of EVs will always be very helpful. In a world where you can get a DV cert in under a second (from LetsEncrypt), if your DNS or domain registration was to be compromised, you’d have no MITM protection at all until you managed to get it revoked - which is likely to take days.

It’d almost be helpful to have a system where certs have to be requested (publicly on CT records) a week in advance or something, so issuance can be protested if something like the above did happen.

Green bar EV caught me by surprise the other day, I did not know what it was and even checked the likes of Google to see if everyone else had one.

This did actually take me away from the checkout of the website I was on, so it kind of broke 'Don't make me think' for me in that instance.

FYI microsoft.com has an EV certificate.

Google.com has a OV certificate, where identity is matched to google.com but this isn't shown in the browser. it's a similar level of verification as EV but without the UI. Note Google have a lot of user generated content (eg, AMP sites) hosted on google.com

YC's website isn't an example of great tech.

(See bio/disclosure in my other comment)

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?

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.

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.

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.

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

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.

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.

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

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.

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:

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

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

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

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?

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

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

Re your scenarios:

I'm not sure users care about domain names in search results (this is measurable) so these two scenerios have similar cases:

They see the owner is ACME Corp and in this case know they're dealing with a site whose legal identity has been vefified, in their own country or one they trust.

Not someone who registered a domain name, not someone in the Phillipines.

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

At least in that case the user knows that they're on the website of a real, legal entity in the UK, and not, for example, a phishing website based in China.

This, to me, is the main value proposition of EV certs. Not a huge deal of course, but significant nonetheless.

> Unfortunately browsers don't make certificate information available to users, and are uninterested in whether users understand what they're connecting to

Sure, if by "Browsers" you mean "the browser made by the Ad Network company that has a vested interest in people using web based computing for everything they do, regardless of security concerns".

My browser (Safari) shows me the domain I'm connected to for DV, and the verified organisation name for EV, and the certificate details are a click away in either case. If Chrome doesn't provide some of that information, thats a fault against Chrome, not the concept of Certificates.

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

Safe Browsing covers malware, and.. maybe phishing?

There are plenty of other things bad actors can do while impersonating well known sites.

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.

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"?

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.

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.

Yeah I don't think google not using a EV certificate really changes whether I can sue them

Obviously the law applies regardless of certificate type, but your ability to prove claims is affected.

At least for top 10 websites, would I not be able to prove that google is responsible for everything on their site?

Probably yes. More probably if the interaction was validated with an EV-cert.

Essentially yes, but that can be established through other channels in legal proceedings involving large, well established actors.

An ev-cert tells the user that the operator of a site has taken pains to make themselves legally accountable, and have confirmed details about juridistiction, legal entity, liason, etc. to the CA, which in turn connects cryptographic non-repudiation to legal non-repudiation (i.e. a signature).

All this is to state that with EV, every http response is basically signed and dated by the legal organisation that operates the site (grossly simplified, but sufficient for this argument). This signals where and how any dispute is to be arbitrated and settled (officially, and possibly legally), and conversely how seriously the security and integrity of the interaction is considered.

The ev-cert acknowledges legal exposure, and therefore it also informs users of legal exposure.

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?

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.

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.

Would the certificate really help you here though? If we look back at most of the big data breaches over the last few years then we regularly find out long after it's happened. It's generally a news story or a headline somewhere that xyz company was hacked.

I see what you're saying but I can't see where this would happen whilst the user has the browser window open showing EV information. If Twitter leaks your data you'd likely get an email notifying you or watch it on the news and then take action as a result of that.

If the validation process to obtain a certificate is rigorous then you have little deniability if and when you are held accountable for any shenanigans. Where I work, if the process to obtain a certificate is rigorous enough, certain entrusted CAs can issue certificates with legal non-repudiation (legal signature) and identifying power. This is written into law. You can bet your car this will create tons of case law when GDPR lands.

The EV-cert doesn't help twitter or facebook (other than making them seem more trustworthy), it doesn't provide any extra cryptographic or operational security, it helps the user better ascertain who is accountable and where when the shit inevitably hits the fan.

Reply on news.ycombinator.com