Are EV certificates worth it? A technical guide to SSL validation | Hacker News Reader

Are EV certificates worth it? A technical guide to SSL validation

certsimple.com

35 pointsnailer63 comments

I'd be really curious to see some numbers on not the technical side, but the human side.

In the past I've chosen not to buy EV certs not because the process is more involved, but because it just doesn't seem worth the extra cost - I've never heard of someone choosing not to do business because a site had the wrong kind of SSL certificate. Most people would probably put their credit card details into a completely unencrypted website given half a chance.

nod what you really want is someone like usertesting.com to do this, ie, interested in conversion rates, not selling certificates.

This hasn't happened with EV yet, but it did happen with 'site seals' - those images (or in Symantec's case Flash objects) that promote a particular certificate brand in a web page.

CertSimple sells certs that come with a DigiCert 'site seals' but I'll happily tell you that usertesting tested CRO with site seals a little while ago and found out that, in one case, removing 'site seals' completely was better for conversion - apparently reminding people they're not being hacked doesn't inspire confidence. Let me know and I'll dig up the event recording.

I feel EV is a different situation - it's the only chrome displayed by the actual browser concerning identity of a website (which as we know is not the same ting as the origin). But I don't have numbers to say and I shouldn't be the one to conduct the research since I'm clearly biased.

This might be an unfair question: Do you see the cost of EV certificates coming down in the future, or is that level of cost actually required due to how involved validation is?

For a lot of SMBs and individuals it is hard to justify additional $150 a EV certificate costs. Plus the loss of convenience that wildcard DV certificates provide (and EV certificates cannot).

I like the concept of EV, but unless I was running a large company with deep pockets or was in a sector where EV is helping (e.g. finance/payments/etc) then I'd just skip it. I'm not even sure it helps mitigate phishing.

Essentially the cost of EV is the cost of validation. As time goes on, and as there are more CAs, I suspect the competition will increase and the price of EV will go down.

However, the current per-year price of EV is less than a half day's work by an average programmer. I'm not necessary sure that's out of the question for most businesses.

We went 100% SSL years ago and EV. Conversions increased over 30%. However we do sell Certs so that probably helped.

What did reduce was the "are you legit questions".

I tend to think that if EV had a measurably positive impact on conversion, the CAs would have provided reliable data to back it up by now.

The CAs have stats on EV conversion - but it's their data, so it's meaningless. It really needs someone focused on conversation rates to test, rather than the SSL industry.

Right. That's sort of what I mean by "reliable data"; to commission an independent study or something similar.

That sounds all great and fancy, but one quite critical piece is missing: the ability to trust CA's. I'm frankly somewhat impressed at the level of diligence described in the article, if it is really what happens for each and every EV cert from every CA. But the cynic in me finds it it difficult to trust that that would be the case. Does the EV certification process put any requirements on the CA, such as mandatory independent audits or some other overwatch mechanism?

EV is simply a signal that the website is backed by a real company. Even if you can't trust the CA's to always do a good job (there are too many instances of CA's really doing the opposite), they still don't give them away for free. To get one, you have to be prepared to spend hundreds of dollars on top of the typical incorporation and startup costs, so at least you can trust that someone actually ponied up for the certificate cost itself, incorporated, and maintains that incorporation in good standing.

We bought EV for https://Userify.com even though we're a startup, because it demonstrates our level of commitment to security and that we're serious in the marketplace. We also use a wildcard TLS certificate for customer-specific logins. EV-TLS also fights phishing attacks.

It's somewhat shocking that AWS doesn't use EV-TLS for the console login, especially when they're so good about other things (like searching for customer keys on Github, watching for phishing exploits, etc.)

Amazon is known to pinch pennies. Anything Jeff can do to save a few grand.

In case anyone was confused and thought you had a Wildcard EV certificate for subdomains/customer-specific logins, that (still) isn't possible, what you probably meant was that you have a regular wildcard certificate for the subdomains in addition to the EV certificate for your primary domain.

That's absolutely correct and thanks for clarifying my imprecise language. I actually support that EV doesn't support wildcards and don't mind buying both. Wildcards can be harder/riskier to manage in large organizations but the specificity of EV means they're just naturally going to be shared around the organization a lot less.

> AWS doesn't use EV-TLS for the console login, especially when they're so good about other things

You mean this AMZN?:

http://imgur.com/S1Pz155,TdRDjIq#0

It's shocking to me that they aren't even using proper TLS settings even though I'm sure they're perfectly capable and aware. Doesn't inspire confidence in their security.

Agreed! (but, in fairness, portal.aws.amazon.com might be an obsolete domain, since it just redirects to the correct aws.amazon.com... the actual console login does use TLS 1.2 etc.)

Even so, it still blows my mind that even the main Amazon.com main page uses no SSL at all by default, and they're an e-commerce site, unlike Google and FB. Seems to show a lack of respect for customer privacy.

> Does the EV certification process put any requirements on the CA, such as mandatory independent audits or some other overwatch mechanism?

CAs are audited (to reiterate) for compliance every year on three audit standards:

- WebTrust for CAs

- WebTrust for CAs EV

- CA/B Baseline Requirements

There is another standard, used by some in the EU, ETSI TS 102 042, which replaces WebTrust. The auditors are always independent of the CA. Unfortunately, the audit reports are not public but management attestations are.

https://certly.io/audits.php has links to GlobalSign and Comodo statements if you're curious.

> Does the EV certification process put any requirements on the CA, such as mandatory independent audits or some other overwatch mechanism?

The EV Requirements themselves do not.

However Google required since Jan 1 2015 that ALL EV certificates have certificate transparency enabled. See the links in the article - I've tweaked it a little to directly address your point too.

Certificate Transparency makes it much harder for a CA to issue a certificate for someone else's keypair in your name.

EDIT: here's an answer for Zokier's excellent question (I'm rate limited right now):

> Does the EV certification process put any requirements on the CA, such as mandatory independent audits or some other overwatch mechanism?

The EV Requirements themselves do not.

However Google required since Jan 1 2015 that ALL EV certificates have certificate transparency enabled. See the links in the article - I've tweaked it a little to directly address your point too.

Certificate Transparency makes it much harder for a CA to issue a certificate for someone else's keypair in your name.

------------

Original response below:

Hi there, author here. I hope you don't mind the foul language but I couldn't convey the general feeling towards CAs at EdgeConf much better.

This is by no means a replacement for reading the EV requirements (and baseline requirements) but does capture the typical validation process for all the (around 30) EV certificates we've been involved in so far.

From the average user's POV: no

They won't know the difference between a lock and a green bar. I would bet a percentage of users don't even notice if they are browsing an site using SSL or even understand why HTTP without SSL is bad. This was proven with tools like Firesheep where people are more than happy to browse facebook on an open wifi connection without using SSL.

I know I saw a discussion with the Chrome team talking about showing an error-like page for all non HTTPS traffic. This is not the solution - the solution is to show some sort of message to the user that is non-blocking that says "hey your information is sent in the clear". Also - change the self-signed SSL to not look like an error page. Using self-signed SSL is more secure than not using SSL at all - even if the certificate isn't verified your data over the wire is encrypted.

I am a Chinese and here most websites don't even use TLS to encrypt the login page, let alone the whole websites. No one bats an eye. Every time I raise the issue it was just met with indifference.

At least browsing Facebook in open wifi (several years ago) leaked only the cookies not the password.

> They won't know the difference between a lock and a green bar. I would bet a percentage of users don't even notice if they are browsing an site using SSL or even understand why HTTP without SSL is bad.

I would bet this percentage is much higher than many people here think. Most people have no idea what "http" means, or even what a protocol is or why they would need one, much less URLs, HTTPS, SSL certs, encryption, identity, validation, etc. Many users whom I observe don't understand the URL field. If they want to load http://cnn.com, they type "cnn" into the Google search field and click the first link -- for sites they regularly visit, every time, multiple times per day! Many don't know what a web browser is. [1]

The idea that they will grasp EV certs, and all knowledge required for that it (certs, issuers, identity, encryption, what does encryption have to do with identity, etc etc etc) seems very unlikely.

[1] https://www.youtube.com/watch?v=o4MwTvtyrUQ

> they type "cnn" into the Google search field and click the first link

Yeah, they even click the ad links, which makes me cringe every time.

You can't have encryption without authentication. So self-signed needs an error because it looks exactly like an attack.

The only time its OK to not warn about self-signed is if you're using HTTP (unencrypted) and the browser did some opportunistic upgrade to prevent totally passive attacks. But no indicator of security should be shown at all.

> You can't have encryption without authentication.

Sure you can - symmetric encryption. If you have the same key to encrypt and decrypt - you can't be sure you are talking to a good guy on the other end.

I think what you mean is you can't have secure communication over HTTP without authentication - which I would agree with. But there are ways to accomplish that without a CA such as certificate pinning. Right now though - only technical people would know how to do that. There should be a non-scary button that shows up the first time to a friendly page that says "I don't trust the certificate that was presented - but this is the first time you are going to the page - would you like for me to continue and remember the certificate for future connections?" Obviously something a little more user friendly - but I think you get the idea.

> So self-signed needs an error because it looks exactly like an attack.

Same logic applies to HTTP then - without SSL you can't know for sure if there is an attacker in the middle or even if you are talking to a bad guys server. Self signed certificate will at least make it so that people that web traffic sent over open wifi won't be sent in the clear. It could be a guy doing a MITM attack - sure but he could have just as easily MITM your HTTP traffic.

However, showing an error page for HTTP traffic would be insane and have a huge drop in web traffic due to people not knowing what to do.

You seem to be in favor of the current CA system - if recent history has taught us anything (superfish ring a bell?) - that the current system is completely and utterly broken. Do you check on a regular basis the list of CA certs that are installed on your system? If not - how do you know that you don't have a CA cert that was put there without your knowledge - that would allow someone to sign an SSL certificate for any domain on the planet and your computer or mobile device will automatically accept it.

Unauthenticated symmetric encryption is full of problems.

Using the HTTPS URI schema indicates you're asking for a secured connection. That is why the errors exist. Not because of some general security principle. HTTP has no security connotation hence no issues.

The CA system isn't great. But it's far from totally broken. Ask CNNIC about how issuing bad CA certs worked out for them.

> Using the HTTPS URI schema indicates you're asking for a secured connection. That is why the errors exist.

Having a self signed certificate isn't an error in the encryption negotiation (fatal) but a policy error (non-fatal). In technical terms - there is nothing wrong with a self signed certificate preventing me from having an encrypted session.

> HTTP has no security connotation hence no issues.

I think you just pointed out the problem - HTTP shouldn't exist at all - we should be migrating everything to HTTPS or some other protocol. I'm not sure letsencrypt is the answer - it might just turn into another non-maintained CA (see startssl).

> But it's far from totally broken.

The simple fact that CAs can, and have, been compromised in the past proves they are broken. If a fraudulent certificate is signed - it doesn't matter if is added to a CRL in 5 hours or 5 minutes - the bad guy has probably already used it to do damage. I'm not saying CAs are pointless - I'm advocating for a way to have a CA that is only allowed to sign certificates for certain domains - especially if I can be my own CA. Yes, I know that's not the way it works now - but surely we can modify the infrastructure to allow this.

> In technical terms - there is nothing wrong with a self signed certificate preventing me from having an encrypted session.

Yes there is - the ability to verify identity and hence actually prevent MITM attacks. (And in most cases where an attacker has access to read a network, they can write to it, too.) You can't ignore key distribution no matter how annoying it is. It's really that simple.

If a CA issues a false cert, that becomes a mathematical fact, and the CA gets revoked. Few entities can afford to burn lots of CAs. But anyways, plenty of people are working on this issue, with many suggestions, some even in place (cert pinning). Some trade the current CAs for total trust in the registrars. Others rely on reporting and monitoring to try to build up an idea of trustworthiness (e.g., if a site is presenting you a new cert from a different CA, especially if others aren't seeing it, alarm). Security here is simply not a binary thing.

> Yes there is - the ability to verify identity and hence actually prevent MITM attacks.

In asymmetric encryption - we both will generate a public/private key pair. We can walk up to each other, exchange USB drives containing public keys, and now we can communicate securely. We have just created a secure connection without a certificate.

All the CA is a middle guy that says "Oh you want to talk to someone claiming to be Alice? Get their public key and I'll verify it as I know Alice." But really how do you trust that middle guy?

> And in most cases where an attacker has access to read a network, they can write to it, too.

Well maybe - put it into context. If a wifi system is open - it's extremely easy to sniff packets (shown by the success of Firesheep). ARP spoofing and other tricks are more complicated - but less likely to happen (someone would have to prop this on a table and it would be a dead giveaway that they are up to no good [1]).

> You can't ignore key distribution no matter how annoying it is.

I'm not ignoring it - I just want to shift it from having central CAs that can sign certificates for any domain (superfish anyone?) to CA certificates that can only sign for specific domains. Perhaps the CA certificate could be stored in DNS (even glued to the domain like NS records are)? Perhaps we keep the current CAs but force them to allow them to sign a CA cert that is restricted to a certain domain (for free or next to free)?

> If a CA issues a false cert, that becomes a mathematical fact, and the CA gets revoked.

That doesn't matter - if I'm a bad guy and find this I know I would only have a limited time before it's discovered. So, if I'm a smart bad guy I find a targeted attack, get the bad certificate and do my attack. By the time people figure out what happened - my attack is over and I got what I wanted. Just think of the amount of damage that could be done in a busy place with free wifi and a bad gmail.com certificate. I'm waiting for the day that happens and everyone can't understand why their [insert service provider] account was compromised...

> Security here is simply not a binary thing.

I never said it was - but the current system is broken [2] [3] [4] [5]. Even Schneier says it's broken - which I find he is pretty respectable in the crypto industry.

[1] http://i.imgur.com/MFbOE0C.png

[2] http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi...

[3] https://www.schneier.com/blog/archives/2015/03/chinese_ca_is...

[4] http://arstechnica.com/security/2011/09/comodo-hacker-i-hack...

[5] http://waf-devel.blogspot.com/2015/04/stop-blaming-chinese-w...

If we're to meet in person, how do you know it's me? How do you know someone didn't kidnap me then go in my place? You'd go seek third party validation either via looking up my picture somewhere or checking my passport. I'm not sure what your point is. Self-signed certs simply do not work unless you find another way to validate. They cannot be used as-is to provide "encryption without authentication"; such a thing simply does not exist.

CA name restrictions are already a thing, but doesn't really solve the problem. Moving to DNS like DNSSEC just changes from the CA to the registrars and hence world governments. And it's a lot harder to block a registrar than a CA...

> the amount of damage that could be done in a busy place with free wifi and a bad gmail.com certificate

This has happened. Chrome detects it, fails the connection, reports the problem, and the CA gets killed. It's pretty much what happened to CNNIC via an idiotic intermediary by accident.

Suggestion to the author: I could really benefit from a short sentence that explains to me what DV means. I get from the context that EV likely means "Extended Validation". Then again, all I ever did was set up SSL on Heroku and a bit of openssl magic to get Github running - so maybe not the target for the article?

Edit for clarification: There is a short description of DV & EV, but it doesn't mention what DV/EV stands for. I'd love to know that (without Googling, because lazy).

I think it's Domain Validation.

As perfTerm noted, DV stands for Domain Validation. DV is where, basically, you prove ("validate") that you own the domain you're requesting a certificate for, typically by being able to receive an e-mail sent to one of the contacts listed in WHOIS for the domain.

This is similar to Google requiring you to create a file in the root directory of a web site or creating a TXT RR (with a specific value) in the DNS zone for a domain for Google Analytics (if you've ever done that).

Here's the thing, the reason EV SSL certificates aren't a good purchase is nothing to do with the technicalities of the matter.

It has to do with "will users trust my site more if they see an EV cert"

And the answer to that (IMHO) is, no, definitely not.

Most users don't even notice when a site goes from HTTPS to HTTP, the chances that they will notice the difference between the display of an EV cert. and a DV cert. is negligable.

Ask yourself this, can you list the sites that you visit that use EV certs? If you can't, what's the chances your users will....

Prove that they don't.

Well, my bank uses an EV cert. That's one of the few that matter.

Of the last few sites where I brought something, most use a DV cert. I always check that, but I don't mind them not having an EV (I only mind plain text and bad crypto).

Of course, I don't want to imply that my behavior is typical, because it's not. I'm just answering your question...

EV-SSL is a browser signal and is not usually visible on mobile, so it will probably have decreasing importance over time.

When EV is used, iOS ONLY shows the EV information - not the URL - in the address bar.

Good to know. Android shows green URL, not EV.

> When EV is used, iOS ONLY shows the EV information - not the URL - in the address bar.

I expect only a tiny portion of users understands this.

Any info on how the /companies API collects data? eg https://certsimple.com/companies?legal-name=testing&country-...

Technically I'd say no. I had to apply for one when I was the lead software developer at a healthcare startup two years ago, and it was more involved. My boss had to submit a bunch of paperwork.

summary of article: no... assuming you've got £15 to set up a company (such as the pirate one in the article), and £149 for a cert, anyone can have one

That's not an accurate summary. The certificate is that you're at that company: only someone with sufficient authority in that specific company can acquire a certificate saying you're that company.

As the article mentions, that not to say there isn't flaws in the process. But most attacks against EV have come in the form of DV downgrades rather than falsely issued EV certificates.

Actually, if you have info on any falsely issued EV certificates I'd be really interested.

right, so if I have £15, I can pay £15 to Companies House to start a company, and then I can authorise anything.

EV offers nothing over normal certs, other than the company name and the green bar, and I can control the company name if I have another £15...

You can authorise a certificate only for the company you just created, which is most definitely not 'anything'

What stops a Russian EV cert vendor for authorizing a EV cert for impostor company Example LLC, when the real corp is Example Inc?

> What stops a Russian EV cert vendor for authorizing a EV cert for impostor company Example LLC, when the real corp is Example Inc?

- The Registry of Companies & Intellectual Property in Russia must accept Example LLC as a valid business name which may be difficult if Example Inc was well known.

- The issuing CA must manually inspect all requested domain names in the EV cert and ensure there is no phishing attempt. A certificate request for the hostname 'example.com.example.ru' would be rejected. Depending on how well known Example Inc is - eg, say they were Bank of America - even 'example.ru' may be rejected.

- If for some reason this failed and a certificate for the identically named Russian company was issued, it would read 'Example LLC [RU]' in the address bar rather than 'Example Inc [US]'

Obligatory comment pointing out that SSL certificates are a racket and it's appalling that we have to pay for an SSL certificate.

If you're okay with not having "authenticated pulls" (i.e., the request from the CF edge to your server being unencrypted), Cloudflare gives you SSL for free. Their SSL config gets an A+ on SSLLabs tester, too.

Far from a solution to the SSL problem, but an interesting and free option for a lot of sites that otherwise would not bother with SSL.

But then you end up visibly sharing a certificate with "nigerian-prince.com" - http://www.slate.com/blogs/future_tense/2015/03/23/ted_cruz_...

This is great. I guess that is indeed a con of the CF approach!

I wonder why Cloudflare doesn't sign certs for their users to be used just for CF connecting to them. Seems like an obvious step to take.

That would go against their "setup only takes five minutes!" mantra. It's an interesting idea, though.

They do. It's a part of their "Universal SSL" [0] called "Strict Mode".

[0]: https://blog.cloudflare.com/universal-ssl-encryption-all-the...

Well I feel silly. I looked in the dashboard several times, but the "valid cert required" was a CA-issued one, I thought. Cool!

Oh, this is awesome. Thanks for the link! No excuse not to SSL all your sites now.

The article was only about Extended Validation, which by definition require extra validation (which is, to some extent, actual manual work by the issuer). Although some might argue that extremely high pricing makes it a 'racket', people generally don't do boring manual labor for fee, especially for the companies that are using EV to make money. (Individuals cannot get EV.)

The problem with EV is that getting one doesn't prevent other CAs from issuing illegitimate (non-EV) certificates for the same domain.

I'd be much more willing to pay for EV if that somehow could simultaneously make it technically impossible for parallel certs to be issued. That would provide actual value. But not when all you are paying for is just a bitflag that causes browser chrome to change slightly.

That's true, but EV on its own does provide real value as well.

When you see the green bar, it's proof that it's at least nominally certified to be served from the entity displayed (barring key theft etc).

Barring parallel certs, even if it was possible, wouldn't necessarily be a good idea, since there's a lot of legitimate uses for them. For instance, we also have a wildcard (non-EV) certificate for the same domain, covering *.userify.com that we currently use for customer subdomains.

I'm far from an apologist for CA's. I think the entire system is broken. It's ridiculous that my browser trusts a Chinese govt CA with the same level of trust as the best US or EU CA, and it's ridiculous that it's so hard for me to customize that level of trust. Still, it's what we have right now.

EV does represent some actual effort for every single issued certificate on the part of the CA's, and they do deserve to get paid for that. Whether that payment should cost many hundreds or even thousands of dollars is debatable, however!

EV is kinda what the CAs should have done from the beginning anyways for any certificate. :-/

Btw, for parallel certs on customer subdomains, that sounds like a very niche use cache. Maybe you could have used a different base domain for user content. (Isn't that best practice anyways, to avoid xss'ing cookies onto the main site?)

Agreed! And wayyy back when (until the late 90's I think), all SSL certificates were actually identity certified, but then cheaper DV certs became common -- but still operating under the same trust model (no way to show the user that you spent more for a better certificate). Even now, lots of CA's charge you for organizational authentication even though there's no EV bar[1], which is just dumb -- since those certificates really don't prove anything more to the user than much cheaper DV certs. I like DV certs because they enable cheap (or completely free[2]) crypto, but EV-TLS does have a valid purpose for orgs that need it.

Lots of startups do wildcard for customer hostnames. (Freshbooks, Campaign Monitor, I'm sure there are many more.) But we're actually moving away from it anyway.

Incidentally, Same Origin policy prevents XSS or cookies across domains like that[2], so e.g. userify.github.com would actually be safer than github.com/userify.

1. https://www.symantec.com/page.jsp?id=compare-ssl-certificate...

2. https://letsencrypt.org/

3. https://en.wikipedia.org/wiki/Same-origin_policy#Origin_dete...

EDIT: good point, iirc Microsoft even had an SSL cert spoofed that way one time.. or maybe it was a domain.

Agreed re: EV should be been what happened from the beginning, but there was some pretty bad late 90s SSL too: I remember having a 'fax on company letterhead' as being sufficient for getting a (what's now called) a DV cert back in the day.

Without OCSP stapling, every time someone connects to your server via HTTPS their client will check with the CA's OCSP server to verify that the certificate is still valid. They maintain CRL's for certificates etc. For DV certificates less so and EV certificates more so, the CA also verifies your information before issuing certificates.

This infrastructure is not free. But yes, technically CA's could issue certificates for absolutely everyone for near-zero cost and they would be just as good as the ones that cost more.

Reply on news.ycombinator.com