I run infra for a payments company and switched our main website from EV to DV last month silently. This is the landing website, not the application (which had always been DV). There have been ZERO people who have noticed, including peers in my Infra or Security teams.
It's obvious that EV does nothing for end users these days, which is why I think these "EVs are useless" articles from Troy and others are kind of silly, like dunking over a person with two broken legs.
I think the far more interesting question is why EV certs do nothing for end users, and why browser makers have not introduced any new features to replace what EV certs were intended to do: help end users understand which websites they can trust on first visit.
The entire Internet industry has absolutely punted on this problem. It's a hard problem, but no one is trying to solve it!
And it is absolutely striking to compare against how well this problem has been solved in real life, at least in the U.S. You can walk into any retail establishment in the nation and reasonably expect to have a safe, productive interaction with a proprietor you don't know--even on the first visit.
It's the exact opposite on the Internet, and it's insane that everyone just accepts that.
These "EVs are useless" articles are still good for something - ammo to convince your boss that they really shouldn't bother paying for an EV certificate.
> this problem has been solved in real life, at least in the U.S.
I haven't spent enough time in the US to have an opinion about it, but in many places this is not true. For example, taxi services in many countries seem to pretty commonly be ripe for dodgy behaviours with little accountability.
It's really about that accountability - what are you going to do against an internet entity which scammed you? How effective is that action going to be?
> It's really about that accountability - what are you going to do against an internet entity which scammed you? How effective is that action going to be?
Accountability was supposed to be the extra value of OV and EV certificates.
Common Name = www.walmart.com
Organization = "Wal-Mart Stores, Inc."
Locality = Bentonville
State = Arkansas
Country = US
The certificate authority (GlobalSign in this case) is attesting that this is accurate identification information for this company--that you can use this information to locate legal records for the company and contact it, sue it, investigate it, prosecute it, etc. DV certs do not have the bottom 4 fields.
That's what the famous "green banner" in the address bar was supposed to convey--that this website has a paper trail that can be used to impose accountability.
That's NOT a guarantee that the website will treat you well. It is a guarantee that you can try to do something if it doesn't. Even if a corporation is only established temporarily for the purposes of getting an EV cert to run a scam, that still leaves a legal paper trail. DV certs do not.
And this is a standards-based distributed system. It doesn't rely on one company like Google or Microsoft, or one particular browser, or even one particular CA. If Wal-Mart doesn't like GlobalSign anymore, they can go to another CA like Digicert. If you don't like Chrome, you can use Firefox--they can both read this cert information equally well.
IMO it is really a shame that the Internet industry was not able to lean into this concept of accountability. For example, why don't browsers surface this company contact info directly to consumers? The way that a consumer can easily find the street address for a store they visit? Instead it's buried 4 clicks deep in a complicated cert menu. Why don't they supplement it with a link to the corporate record of the company? Or to the Dun and Bradstreet listin? Or to the police department website in the registered locality? (Bentonville, AR in the case of Walmart) Or to the Better Business Bureau in that state?
It just seems like there was been the opposite of innovation into this concept of using certs to provide IRL accountability for websites.
For accountability: Knowing who to sue doesn't really get my $50 back from some jerk. The effort put into small claims makes it a net loss. My best option is a chargeback, and the cert doesn't do anything.
For reputation: I have no idea if that's the company name of Wal-Mart. It's barely better than verifying the domain name.
If you walked into a store on Main Street and got scammed for $50, would you just throw up your hands? Or would you call the cops? If you did call the cops, they would have the address of the store to start their investigation. And aside from maybe getting you your $50 back, the state might prosecute the scammer for committing a crime.
EV and OV certs are intended to provide similar information. If you report a scam by a website with an EV or OV cert, the police can use the information in the cert to start their investigations. There's more to accountability than small claims court.
Setting aside the cert issue, it's just striking how many people take it for granted that there are no consequences and no recourse for online crimes. How did we come to accept this as normal, as a society?
If you're a site operator, it could definitely make sense to have cert checks (e.g. can I assess this cert as trustworthy, will it still be valid 28 days from now) as part of your high level system dashboard. A site with a busted cert is as broken as one that gives 404 errors to all visitors or crashes and won't load at all.
Having somebody else do this for you makes some sense, but again it makes sense as part of a whole system dashboard, you care if your site gives 404s to everyone outside the VPN as well.
Bad guys _mostly_ don't start by getting illegitimate certs issued. For the DNS hijack stuff for example, even where a cert was issued we see it significantly _after_ the traces of the hijack are visible. The bad guys lie in DNS and _then_ they might get themselves certs so they can run an HTTPS site, you ideally want to detect the DNS hijack as otherwise you're already playing catchup before the first pager alert happens, and these attacks may last just hours or even minutes, so every second counts.
Without DNS hijack, they're mostly doing phishing, so you won't see new certs for your site, because you know you're legitimate.site.example and not legit-site.example or login-legit.badguys.example. Your customers, alas, not so much.
You can get MitM on a smaller scale by simply spoofing WiFi SSIDs.
It used to be that spoofed WiFi and SSL-strip (a program that terminates all HTTPS connections and forwards them as HTTP) would work pretty well for that.
These days HSTS should stop most of that.
HSTS has been adopted by the big ones, (e.g. gmail, paypal, lastpass). I'd say these are also the ones where it might work out to drop a pineapple in some NYC coffeeshops.
It isn't widely deployed though, so it'll still do some damage.
I guess criminals don't wanna do the sleuthing to figure out where they found creds.
I didn't think SSL-strip could work as described (unless you trusted the cert chain), so I did a little reading.
It seems like it works by intercepting traffic and downgrading the attacked machine's connections to http. So, your text is correct; it is terminating the https connection "the other way 'round" from the way I first read your text. It's https from the MITM machine to the "real" server, but http from the browser to the MITM machine, rather than the MITM machine being able to terminate the https session from the browser (without a cert error).
Sharing in case that helps someone else not have to google for "hey, I don't think that will work the way it's described".
I'm surprised no one has mentioned the main practical benefit of EV certs: the fact that a green cert in the browser ensures that there is no man-in-the-middle network proxy/appliance intercepting the traffic even if a trusted certificate for the proxy/appliance (or bad guy) has been placed in your machine's cert store. Browsers will only honor the EV setting in the cert if it was signed by a hardwired (and much shorter) list of CAs.
As long as you, the user, trust that the browser itself hasn't been modified (for example if you downloaded it yourself), then it's a nice reassurance when using a browser in a not totally trusted environment.
Browsers are moving away from showing differences between EV and DV certs nowadays though. And anyone can register a company name and get an EV cert - that doesn't make it trusted. https://stripe.ian.sh/ is a prime example of this.
HTTPS is a nice reassurance, sure, but an EV cert isn't.
The article is precisely about this: regardless of practical use, people don't follow the behaviour associated with supporting that practice, so it's worthless.
And people who would follow the correct behaviour...are probably capable of doing so without the EV anyway.
No, I don't believe it is. The point debunked over and over again by Troy in this and other articles of his is the supposed anti-phishing aspect of EV certs: that because the browser shows the company name separate from the url, the user can know that they're really at e.g. Amazon and not amaz0n.com.
I'm referring to a very specific situation that is much more rarely mentioned: when you are using a computer with a managed cert store (usually a company computer behind a firewall) and you want to know if the site you are visiting is getting "legitimately" (per company policy) SSL-sniffed by a network appliance. This is completely different from phishing attacks or whether you think you are at the real Amazon. All you need to do is go to a single site that you know has EV and see if it shows up as EV in the browser. Sure, they could selectively sniff, but in practice I believe most companies that do this have an all or nothing approach.
"PayPal really doesn't care that the world's most popular browser no longer displays the EV visual indicator."
OT but hopefully interesting: Paypal doesn't care about many things. Like keeping their callback JVMs up2date, or changing their UAs from defaults to disguise their enabling tech.
I'm really happy that Paypal ops is not upgrading anything just for the sake of upgrading it. At that scale, changes should be approached with extreme caution.
They're missing out on probably dozens of security fixes from the past 4 years. Unless they depend on buggy behavior, it is incredibly unlikely that they'll have any backwards compatibility issues, and hopefully they would have tests they could run against a newer JVM to help surface those issues.
Firefox 66 does not show EV indicators, either, any more.
But I would also like to point out that PayPal is a known bad player when it comes to phishing, so no one really should give a damn what they do, and if you do the opposite of what PayPal does in security you are probably doing better than them.
I'm seeing the EV indicator with Chrome 74.0.3729.169 on Mac OSX Mojave 10.14 (18A391)
Edit: I also see the EV cert on Firefox 66.0.5 and 67.
I can't really tell if safari has an EV indicator or not? I really don't use it much but it looks like this https://i.imgur.com/9asQkbN.png
Safari version 12.0 (14606.1.36.1.9)
On MacOS, Safari uses the green (as shown in your png) for EV certs. HN does not appear to have an EV cert, as it's a gray padlock (not green). And, Paypal does appear with the EV green on my Mac as well.
Not sure if it's possible, but my money is on incorrect certificate deployment somewhere in the Paypal infrastructure, maybe an incomplete bundle somewhere that is affecting the "EV" evaluation.
> But I would also like to point out that PayPal is a known bad player when it comes to phishing, so no one really should give a damn what they do, and if you do the opposite of what PayPal does in security you are probably doing better than them.
I can't even imagine what you are referring to here. PayPal phishes people? Citation needed, please.
Paypal does its best to make all its emails look like phishing by using a quadrizillion of different origins (stuff like paypal-service.com, paypal-australia.com.au, paypalcustomercommunication.com etc.) and routing links through another set of phishy origins and/or external third parties, and to top it all off they give bogus advice like "You can see this email is from Paypal because we are using your proper first and last name".
A lot of the bigger companies are guilty of this, Google is probably one of the few exceptions, since emails from Google tend to actually originate from ...@google.com, and their logins are all handled through accounts.google.com, unlike e.g. Microsoft which still has a handful of different login portals for the same account on non-microsoft.com domains (such as "msauth.net").
E.g. Dropbox sends emails from half a dozen or so origins, Microsoft uses a bunch, too, including shit like "microsoftmail.com" which rivals some of Paypal's choices for phishiness.
Tangential question: neither McDiarmid's "Kill Sticky Headers" [0] nor its improved version [1] work on this website. Does anyone know how the bookmarklet can be changed to work here?
Making CSP not affect bookmarklets at all (as opposed to not affecting whether they execute) is a different situation entirely, because bookmarklets by definition execute in the JS environment of the page (unlike extensions, say), so it's not really possible to tell apart things that the bookmarklet does from things the page does. For example, what should happen if the bookmarklet calls a page-defined function that then does a subresource load? What if a bookmarklet defines a function to do a subresource load that the page later calls? Note that from the point of view of the JavaScript engine the functions the bookmarklet defines and the ones the page defines are indistinguishable from each other...
It blocked the sticky header for me on this site no problem.
> Description: Web Annoyances Ultralist Sublist for CSS element modifications - Modify site elements that block screen real estate - Primarily used to "pin-in-place" sticky headers, dickbars, floating headers, floating videos, scrolling headers, scrolling videos, stickynavs and other distracting page elements.
On the HN thread on Troy's last post about this, I said [1]:
"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."
Ultimately, this is a bad example to show that EV is pointless. The biggest benefit of EV is as a flawed signal of legitimacy [1] for sites whose URLs aren't widely known and get a fair amount of first-time visitors: web presence for real-life service businesses, specialized payment portals accessed through redirects, and the like.
This is because 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.
EV formalizes the vetting between legal entity and domain name, so it translates okay to entities that are firmly anchored in meatspace. But all of this chaining is trust in people's heads is done by names and strings, and experiments like stripe.ian.sh prove [2] why it's fallible. Nonetheless, EV effectively allows one extra indirection between (1) the name of the business as people refer and recognize it, and (2) the domain name that's likely correct, than DV does -- and some operators and some visitors benefit from this indirection, when the URL doesn't roll off the tongue.
Never forget when ReadWriteWeb posted a blog post entitled "Facebook Wants to Be Your One True Login", which ended up ranking very highly for the search query "facebook login". It was subsequently innundated with comments from angry people who hated the new redesign and couldn't figure out how to log in... believing that they were on facebook, because they googled "facebook login" and clicked the first result.
I forgot about that one. It's interesting how people will hold on to their method of doing things, even if the workaround is harder than doing the direct thing: (one of the comments)
> for those of you that want to get in face book now just go to Bing..put in face book and search (or it will pop up) hit on face book login and it takes you to your password page...i did it....
if this ever gets back to normal I will use the address bar from now on.....
I'm not sure I'd agree with this. I don't think most people look at or really understand URLs or domain names. I think people assume they are a lot "fuzzier" than they are, so "facebookapp.com" or "facebook.foobar.com" or anything else would be assumed to be "Facebook" by most people.
As technical people it's easy for us to assume things that feel basic to us are at least understood but I don't think it's the case. My parents do most of their shopping online, and when I was growing up we always had computers around, but I don't think either one of them really understands URLs or things like file hierarchies, or windowing systems on desktops for example.
I have seen multiple people, mostly elderly, who will go to whatever search engine that loads by default in their browser, search for Facebook, and click on the link. Nothing close to everybody has Facebook's URL memorized.
I remember a few years ago when someone wrote a blog post about Facebook that somehow ranked higher than Facebook itself in Google search results for "facebook login", and was innundated by people who thought they were on facebook and left angry comments about how the redesign was terrible and they couldn't figure out how to log in.
A very non-trivial amount of people type "facebook" into Google and then click the first result.
I found the linked page from ian.sh is extremely instructive. [1] Especially the part about how some browsers hide the domain name when the EV certificate is in use.
I'm with a company that uses EV certificate for our site, mostly just to "look even more trustworthy", even though it functionally servers very little purpose for us, and in an industry where I doubt very few clients know what it really is. For large companies the cost of an EV certificate is negligible. If someone wanted to impersonate us, they would only need to change a letter or two and get a similar `.com` domain, which would be easy to do since we have a somewhat unusual name.
The linked article also talks about the possibility of people getting a shortened domain name like `g.uk` for phishing. If a company has a wide portfolio of sites, that becomes even easier since it weakens peoples association between a canonical domain and the company.
I guess the main point is that the DNS records themselves are one of the most effective preventions of phishing since you need a mapping from a user intent to the site they arrived at. Domain names provide a memorable and easily "mentally verifiable" method of mapping from "facebook.com" -> Social Media, "gmail.com" -> Email, etc. for most people. But strings of characters are also vulnerable since they can be easily changed by a transposition, or other operation, to create a new domain name that looks _very_ similar. Since our minds are much better at recognizing words by the beginning and end, they are vulnerable to changes in letters in the middle.
It makes one wonder if there is a system that would allow much easier mental verifiability of that mapping, but which would still allow a large number of possibilities. Or whitelisting sites that you regularly visit and alerting an individual on sites not in the whitelist or which _resemble_ sites in the whitelist.
EDIT: just to make clear, I think strings and domain checking mentally is a terrible model for verifying trust. But at least it kinda works some of the time, even though there are tons of vulnerabilities and problems. But probably better than typing in raw IP addresses, most of the time.
Thankfully even iOS (I believe starting with 12.2) no longer hides the full domain name when EV is present, but EV will still make the domain's characters turn green.
Security Keys fix the problem of credentials getting phished by making them unphishable (a Security Key will let you give evilguy.example credentials, but only for evilguy.example, they are utterly useless for facebook.com or goodguy.example or any other site, it dumbly refuses to help you give Evil Guy your real goodguy.example credentials)
More subtle manipulations from phishing remain possible, but they're trickier to pull off than just stealing people's passwords.
IIRC somebody has a proof like with Arrow's theorem - that the perfect desirable set of features for names can't be achieved, but I can't find it. Certainly you can see a different trade in Tor hidden services for example, bad guys can't get a name arbitrarily similar to yours, but your name is also mostly gibberish, so your users probably don't remember what it is anyway. Did they buy the last bag from greatweedxstrm4aqp.onion ? Or was it weedxgreatstre6g2q.onion ? And unlike conventional Phishing the plan is probably to break your door down and arrest you if you pick the wrong one which sucks worse than card fraud...
To note: Firefox (Nightly) on desktop for me rendered the false Apple domain near-identically to the real Apple, and for the two RF domains, the Cyrillic was used.
Iirc, the rule being used is the IDN gets rendered unless it crosses character sets. So your domain entirely in Cyrillic or Kanji is fine, but mixing them with Latin characters should be a no-no.
It should be. Unfortunately even really obviously fine cases like Swedish government agencies on the Sweden TLD (försäkringskassan.se), which by the way supposedly has a proper IDN policy that browsers should respect, don't get respected by all modern browsers :(
Looks like this is fixed in Chrome and Edge by default. In Firefox (release 67.0) you have to dig into about:config and flip the switch on network.IDN_show_punycode (this is discussed in the above demonstration article.)
I'm one of those who doesn't pay any attention to those EV cards at all. I know I probably should, just out of completeness, but I don't. In fact, with Firefox anyway, that spot where the EV indicator goes is used for enough weird little things that I've sorta developed a blindness to anything that appears there (I'm not saying that's a good thing!)
However, if I'm going to a site that really matters, I'm not clicking on some link on a web page or email somewhere. I'm using the link I've bookmarked. So, ignoring the EV cert is probably not putting me at too much risk.
The problem is that EVs never got really widespread - even well-known, important sites never used it. So you have to remember if that particular site used to have one, which is a much harder requirement.
"PayPal really doesn't care that the world's most popular browser no longer displays the EV visual indicator."
Funny story - I was about to rant that yeah, it probably wasn't by design because Paypal still as of 2019 didn't offer 2FA which, for a payment company, was quite disturbing...
well, turns out I was wrong, they now do. I just hadn't checked in a while, and of course received no email about it when they did turn it on... or maybe just missed it. Typically something you should advertise on each login if it's not activated, but hey, who cares, it's just money after all.
> Note: yes, I know there can be regulatory requirements for EV in some jurisdictions, but let's not confuse that with it actually doing anything useful
That exactly. Similarly confused about customers who think OV certificates are better than DV - as far as I can tell no end user knows how to tell those apart in their browser (no 'green' locks...)
The certificate fields for organisation, city, etc have existed and were expected to be verified since SSL was created in the nineties. Anyone who has ever made a CSR knows this.
Rolling back from checking the organisation to domain-only validation in 2003 was GeoTrust trying to increase profit margins. Again, Troy should already know this and it's surprising he doesn't seem to.
Oddly enough Troy also Tweets from a verified account, which seems somewhat unusual since a well known username should be enough according to his logic against verifying websites.
Heads up: I run CertSimple, a startup that does faster, simpler verification for EV.
I don't want this to end badly for you (via CertSimple), but as you perhaps come to anticipate my primary concern is always preventing Future Harm. EV hasn't been effective for that purpose.
The article I've just read never uses the phrase "the true meaning of SSL certificates" that I can see, if that was removed I apologise but otherwise I think I have to assume you're putting words in Troy's mouth.
"The certificate fields for organisation, city, etc have existed and were expected to be verified since SSL was created in the nineties. Anyone who has ever made a CSR knows this."
Anyone who understands what's actually going on here knows that these are part of the X.500 directory system and are present in Netscape's SSL because it leverages that systems's X.509 certificate format. In 1999 PKIX (RFC 2459) proposes how to use this system sensibly with the Internet and the modern Web PKI largely falls out of that and its successor documents.
Prior to the CA/B Forum (and the creation of Extended Validation) the only promises you had about what, if anything, in certificates you relied on had been "verified" and to what extent, was written in the legal documents of the issuing CA. In most cases they disclaimed all or almost all responsibility to the extent possible. Their methods were... unsound.
Even today, when if you run Firefox (or more or less, Android) you can actually trust that someone cares whether the validation was done properly, it's more slip-shod than any of us should want. What has Certinomis been up to for the past few years? What are all these certificates doing with ST=Some-State (yes, literally the words "Some-State", because that's the default in OpenSSL)? or L=Default City (again, the default in OpenSSL)?
I think we can reasonably conclude that the reason nobody engaged with my questions about those is that the answers would be embarrassing and they're hoping that if they stay quiet nobody will follow up by asking why they're filling this crap out (to make money) if they can't validate it properly...
> Frankly, I think this is more a symptom of people coming to grips with the true meaning of SSL (or TLS)
I did add 'certificates' so it read better (the system is PKI not SSL) but yes it's from the article.
Yep, they're x509v3 fields. Netscape was under no obligation to include them - they simply could have included CN only if they thought people didn't want to know the organisation they were communicating with.
However Organisation was included by Netscape and it was verified until GeoTrust invented DV (and later other CAs copied it to compete with the low margins of not checking identity. Totally agreed about the poor quality of verification during the 90s though (fax on company letterhead etc).
The one thing that hasn't changed in 20 years is that people still want to know who they're communicating with online.
(DC would also provide a tree structure if Netscape had wanted to use domain names as the exclusive form of identification - but they didn't. The objection was to verify enough information for commerce, which domain names clearly do not)
How long ago was it that users didn't notice or care if the URL was http:// rather than https://? Yet no-one was declaring HTTPS dead on those grounds.
> Apples and encrypted oranges. There's no actual technical difference between EV and DV for the end user, much unlike https vs http...
What does it matter to the end user whether the difference is technical, legal, or procedural? The user just wants to be able to tell the difference between a legit site and a phishing spoof.
> Why does my comment have to be spelled out anyway? I'm having a hard time believing you don't know that or haven't realized it.
The article points out that users and paypal didn't care that their domain wasn't using EV, as if this were a slam-dunk argument against it. But that argument would go through just the same for a domain that wasn't using HTTPS at all.
The difference matters because http vs. https makes a difference regardless of what the user or HN commenters think, whereas EV relies entirely on the user acting in a way that is entirely theoretical and not seen in practice.
