Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Another data point in the ongoing theme of EV certificates having basically no value.

The other big data points being: browsers don't want to display them differently, and users don't notice them being any different.

Now we have that nobody is really checking them that closely.

How much longer will these even exist?



Ours are about to expire. I replaced them with free amazon certificates recently. The process of getting and deploying certificates three years ago was super painful. The process of replacing these certificates was super easy and renewal is now automated. Things have improved a lot since the letsencrypt movement kicked off a few years ago.


I used to pay for certificates. Recently however, I got burned with a crappy Symantec one sold by Name resulting in near continuous customer reports of console errors in Chrome.

I fought with Name to get them to reissue it, they wouldn’t. I decided it was time to figure out how to setup Let’s Encrypt. They lost me as a customer, and I’ll likely never buy a certificate again.


I wish InCommon/internet2 supported ACME. The admins at my work are quite busy as is, and ACME would definitely make for one less factor to be constantly concerned with.


There was https://www.troyhunt.com/extended-validation-certificates-ar... from a year ago.

Max length of a certificate is 2 years, so probably 2020. Maybe 2021-2022 if you count stragglers and businesses that are locked into long contracts.


Mr Hunt also updated this statement recently: https://www.troyhunt.com/extended-validation-certificates-ar... "Extended Validation Certificates are (Really, Really) Dead"


When I saw that google, amazon, apple and Microsoft weren’t bothering with EV certs, I figured I didn’t need to either.


Google's cert is not really domain validated either. They have their own CA.

Microsoft also has a CA.

Apple has EV and Amazon uses DigiCert, which is the only one that may be domain validated, perhaps.


All four of them own publicly trusted CAs. However, they are certainly required to validate all the certificates they issue even to themselves.

Several (all?) of them are domain registrars and so they would be able to rely on that to shortcut issuance validation for names in domains for which they are both registrar and owner, but it still happens it's just easier.


> How much longer will these even exist?

EVs will soon be gone when browsers stop recognizing them. We are already well on our way there. From the same author from a month ago [1]:

> Both Google Chrome and Mozilla Firefox have announced that they plan to move the EV indicator out of their main UI.

[1] https://scotthelme.co.uk/gone-for-ever/


I don't think that's an indication that their CAs will be removed. Correct me if I'm wrong, but they are not less safe than other certificates, they just don't add any additional value. So they will probably be treated the same as other certificates by browsers. If people will continue paying for them is another matter of course (but it might very well happen that they will have many customers for years to last).


EVs and security is a fun topic, including obvious sarcasm. They generally are more secure for 3 reasons:

1) hardfail on revocation checks 2) you can't get around any errors generated by an EV 3) you can't fake them by truststore manipulation (except ie and maybe edge) as the ev roots are hard compiled into the browser and not dependent on the external trust store.

Validation would have been a 4th reasons if it wouldn't be for all the obvious problems with it especially lately.

The problem is what people imply or are made to imply from different cert types.

Back in the day people were told to just check for the lock, which obviously is dumb considering now everyone can get a dv for free.

Then with EV CAs told people that sites with ev are more trustworthy. Obviously nonsense considering the excluded usages of EVs in the cabforum documents. EVs are only supposed to make a hard link between an offline and online legal entity, and even that failed with stripe.ian.sh (although that's not exactly the fault of EVs)

EVs now get so much higher implied security that the real vs implied security ratio is obviously very ugly while DVs becoming standard obviously have much more real security than implied (if people check the urlbar correctly)


That is a good point, I didn't know most of it and it shades a whole new light on the EV topic for me. Especially 3) is a bombshell to me, as I was under the impression that at - least theoretically - the users have control about who they trust.


> browsers don't want to display them differently, and users don't notice them being any different.

That's the only thing that matters, really.

The selling point of EV certificates is that (1) they are very visible in the browser and (2) users care enough about that to make a difference to your business.

I haven't seen any surveys or A/B testing results about (2) but since (1) is no longer true this is moot.

It means you should just go for the cheapest certificate, which means free nowadays.


Firefox displays them differently.


First thing to note is that Firefox is largely irrelevant versus Chrome and Safari in terms of marketshare.

Chrome no longer displays EV certificates differently, I believe, that about 2 thirds of the market.

The second thing is (2) is my previous comment: Even if an EV certificate is displayed differently, does anyone care? Does that impact my business to make it worthwhile?

The general public could not care less, imo.


You're saying that Firefox's 9% is irrelevant versus Safari's 3%?


That's not the point of my comment both regarding EV certificates and regarding relevance of Firefox (and I don't know where you got those stats).


You are clearly excluding mobile browsing stats.


> browsers

EV certs are still useful for code signing. At least on Windows UAC warnings look differently if binary is signed with EV certificate.


These certificates aren't in the Web PKI and so they aren't covered by (most of‡) the Web PKI's rules and there is no requirement to log them publicly before use.

For example they would lack the 1.3.6.1.5.5.7.3.1 EKU which says their purpose is to identify an SSL/TLS server.

The market for these certificates is pretty different from the Web PKI market.

‡ When they're issued by a CA which would also be trusted in the Web PKI some requirements cross over because of that, particularly Mozilla wants to be sure that certificates issued under these hierarchies are never "accidentally" valid in the Web PKI without obeying its rules.


Does it?

Windows is my daily driver, and I'm security-minded - yet I haven't noticed different colours for UAC dialogs depending on signature type. I notice if it's not signed at all, of course, but otherwise... no?

I would imagine most typical end users are the same. Similar to how browsers are not actually, where they make it really obvious if a site doesn't use TLS, otherwise it all looks the same.


The comment you're responding to doesn't make this especially clear, but code signing only /has/ certificates with organisation names subject to an extended validation. The rules for those are:

https://cabforum.org/ev-code-signing-certificate-guidelines/

Whereas for the Web PKI (things that do SSL/TLS, including most obviously HTTPS on the web) there are both the baseline requirements for every certificate:

https://cabforum.org/baseline-requirements-documents/

and EV for adding "extended validation" to that:

https://cabforum.org/extended-validation/

It's kinda useless to have a certificate that says this program is really named "Great Calculator". Oh yeah? So what? Whereas a certificate that says it's from "Microsoft Corp" in "Washington, US" at least tells me whose fault this calculator program is when it wrecks my PC.

On the other hand, knowing this is really https://news.ycombinator.com/ is kinda good because the machine can (and does) automatically check that this matches on every single URL resolved, every image, every HTTP POST, everything.


Oh, I've bought code certificates before - I didn't realise the ridiculous process I had to go through was "extended validation "?!

I had to give them a published telephone number for a callback. I don't publish a phone number, so I setup a Skype Number and published it in a free Yellow Pages kind of site - they did a callback, which obviously totally proves I work for Acme Stuff, and then I removed the listing and Skype Number.

I recall there were a couple of other bits of theatre I had to endure, publishing information on random listing sites that don't do any validation of their own, but I don't remember exact what.


I always thought code signing was a class of its own (especially since i also saw the names of people in those, which directly contradicts EV as ev cannot be obtained by people, only legal entities like companies or govs or whatever) but okay.


Just yesterday someone asked if there was a way to verify if the email from a purchase was leading to the correct domain to log in to. They wanted to make sure they weren’t being phished. How I wished there was a simple button they could have clicked in their browser that would have shown a window with the company details for the website certificate.

Everybody rails on how useless EVs are, yet it seems like no browsers have spent any time over the past years even trying to improve the UX related to certs. I mean, sure they’ve changed the color and removed the ambiguous company name and country. Which makes you ask why did they ever display country in situations where that isn’t the jurisdiction that issues business licenses, such as in the US?

I mean, click on the lock and through N buttons, then expand various sections and read through dotted identifiers that only ASN.1 experts recognize (seriously, who though it would be a good idea to use OIDs for known fields in the UI?), and then maybe you’ll understand who the certificate is issued to.

At least in the US, when obtaining and EV cert you need the jurisdiction (state), business registration number, they call the business phone number. They basically do some research - usually you need a DUNs number, publicly listed phone number, etc. Wouldn’t it make sense to have a button that when you click it you see a user-friendly window showing the information about the company for OV/EV? I mean, sure, you can register Stripe in a different state - how about providing some statistics like what year the company was formed (usually only file with business registration), a link to the company registration details on the jurisdiction website, the top level domain Whois info, etc? If you wanted to get fancy you could provide a link to the user’s search engine with the company name as the search terms.

Instead it seems like we have a bunch of cryptographers (or maybe just infosec people) obsessed about 1. The money companies are charging for EV certs 2. that it is possible for mistakes to happen. This instead of improving how we present information about a company.

So since there isn’t a perfect, foolproof identity verification system for companies online, now every user online needs to do their own reconnaissance to make sure this is really the website they should be at.


You're right in that a working EV system can indeed protect people. However, as this article suggests, even a basic check can be very hard for CAs to implement. If you can't even do a spell check on the state or country name, can you be trusted to verify the identity of those who rely on you to meticulously verify a company?

There's also the point https://stripe.ian.sh/ made: it's not just about registering the same name in a different state. People don't know in what state your (parent company) headquarters are so they would need to dig deep into the organisational structure to find out if the EV cert they're presented with isn't from a company with the same name in another state. Want to add more years of registration? Just buy an old, probably no longer used letterbox company and change the legal name. Whois info can be set to anything you want for most domain registrars as well. People will still need to find out if all the data matches.

There's also this demonstration of how EV can actually be used to help phishing by using the "green address bar" and the hilariously stupid Apple address bar design: https://www.typewritten.net/writer/ev-phishing/

I believe there is value in EV certificates if you can rely on the identity verification that they come with. Sadly, most providers of EV certificates seem to view them as a way to make more money, not as a tool to bring trust to the web.

An EV-like system will probably be reinvented in the future, giving us a fresh start on identify verification on the web without the crappy practises and standards that plague the EV system today.

Lastly, for such a system to work, all (big) companies need EV certificates. Even before browsers started cutting back on EV UI, nobody knew what site does or doesn't have EV. Some subdomains used different certificates, some didn't have certificates at all. How do you know if a (sub)domain is supposed to have an EV certificate? Will you tell people to just not log into Facebook anymore because they don't have an EV at their login page?

EV doesn't work because it's the wrong way around. For security indicators to work, you need to warn for danger instead of turning off the "everything is okay" light. The OV/EV system has been designed around the latter idea and as long as EV/OV isn't freely available all over the world, nobody's going to mark DV certificates as "insecure".


Also ov/ev isn't something a person can get. I mean it might already help for some personal sites if they can be tied to other pseudonyms the user has online so for example sites of more or less well known open source software could get a link to the github or whatever into the cert to directly bind the dev of that software to his website, without having to know who is behind that.

The identity problem is always fun. I mean i don't care who someone is in real life, i only wanna know whether i have the site by the same individual who made something else.

That can be easily and automatically verified (see keybase) and might be more than enough for a lot of things where there are only normal people involved.

It might also be helpful of a given company is more commonly known behind another online entity. Like for example if pewdiepie had a company which he uses for what he does, the link to his yt would be a much greater indicator of validity than some random company name or even his own real name (which not everyone may know).

For pure DVs i think they should be able to issue them themselves. I mean the only thing those prove is domain control and with dnssec+tlsa there's a great way that domain owners can prove that they are in control of the domain and aurhorize a cert, also this lowers the number of trust paths significantly as there is only one possibly trust path over the TLD, and not like 150 CAs from who knows where. Also both the domain owners and the users have less entities they have to trust, as the TLD managers have to be trusted anyway as they ultimately have the full control of their domains,and thereby could make a DV cert themselves over the CAs anyway.


Your proposal seems like it doesn't really change anything? Users are still left to "do their own reconnaissance".

Research suggests they don't do a very good job at that.


No, I think his point is that you need to provide a good amount of info to get an EV certificate, but then almost none of that info is included in the certificate. Combine that with the fact that what little relevant info about the certificate is buried in a relatively hard to find (for the average user) section of their browser, and it's no wonder that EV certificates have gone from "expensive novelty that nobody notices" to "effectively pointless"


> improve the UX related to certs

They’re actively making them worse, actually. I can’t even view the details of the certificate chain in Chrome on iOS. I used to be able to save them from the browser on a computer, and now I can’t do that, either.


Can't do that on safari either for some reason; this is confusing since there are apps like TLS inspector [0] that can show the certificate info.

0: https://tlsinspector.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: