Extended Validation Certificates Are Really Dead
troyhunt.com
troyhunt.com
The problem is that legal corporation names are much harder to verify than domain names, and even once verified they don't always match user expectations (as Ian Carroll so aptly demonstrated with his Stripe Inc. certificate). Furthermore, and perhaps partially as a result of the aforementioned issues, browsers don't treat EV certificates in a way which would allow any meaningful security guarantees to be built on top of them.
I wonder if there are ways this situation could be improved. Brand names, for example, are probably more likely to match user expectations than legal company names. Perhaps an alternative to EV could be built around that idea.
You can surely get "Stripe Inc" in another country i.e. it isn't just an issue that can be solved at a federal level.
Neither are trademarks useful because they are: per nation, per class (of goods or services), and are not pure text (icon matters).
Stripe (Financial Services) [US]
And that is just one, US-centric, piece of the puzzle. We got into a terrible situation with corporate legal entities; trademarks will not help either.
(Also pretty disappointed you are not going to point out the fact you run a company dedicated to selling EV certificates: https://certsimple.com/)
I've also discussed how trademark information could be incorporated into verification markers extensively with Ryan Sleevi on Twitter. You should follow us both if you missed the discussion.
Attempting to embed additional visible info in the cert requires some centralized consensus, and trusted validation that certs being provisioned match the consensus. And all of this occurs despite the continued fact that end users do not even look at the certificate information anyways, so we’ve deployed a new central body with a bunch of administrative overhead and not moved the needle on actual security.
As discussed earlier elsewhere, browser verification markers are outdated - users can and do look at modern verification markers. Google themselves use them in the Play store and for every member of the Chrome team's Twitter accounts.
Also: how does a “modern” verification marker differ from an “outdated” one? The research seems to show that users are terrible at deciding that something is unsafe based on the absence of a marking, regardless of how new and hip the marking is.
Short version: it would be very difficult to obtain a trademark for 'Stripe' for 'online transactions'.
As mentioned elsewhere, modern verification markers can be found on Twitter, Whatsapp, Facebook, Apple's App Store and Google Play. They are well recognized and should have interesting test results, if Google actually was interested in testing what effective verification would look like.
Even if you would have reasonable alternative such as brand name or else, simply having this in address bar in green does not help people to differentiate phishing sites without brand name in progress bar. People see the same layout and colors on the page and assume it is correct one.
I acknowledge it's a bit harder, since not every site necessarily _needs_ full identity verification. (I don't really care about the legal entity that owns Hacker News, for example, I just care that it's the same site I signed up for back when I first created my account.) But for the sites where it _does_ matter, there's no reason why efforts couldn't be made to shift towards negative security indicators. (For example, perhaps browsers could warn users when the legal entity that owns a site changes.)
> This key belongs to the owner of this domain name AND this domain name matches this business name.
Instead, an EV cert comes with an extra name (the official business name) and then asserts:
> This key belongs to the owner of this domain name AND this key belongs to the owner of this other business name
Hence you get the image [1] of a website www.thesslstore.com but EV business name 'Rapid Web Services LLC'. Should that really mean that this counts as a 'verfied' domain that gets a tick-mark?
That said, switching to a system more like the first assertion, and going with the 'verified' tick mark could work. It would make validating EV certs a lot harder though, as it requires a more subjective judgement to make. (e.g. could you validate windows.com for the company microsoft? What about youtu.be for youtube) Making a wrong judgement here should look pretty bad for a cert-issuer.
[1] https://www.troyhunt.com/content/images/2019/08/image-4.png
- Using trademarks (this fixes the US issue of per-state homonym attacks).
- Not including the domain in the certificate at all. If an identity is verified, it's verified. Why limit where it can be used, or try and assert some unrelated fact?
The SSL Store (Computer Services) [US]
I strongly disagree. It is still a domain that is entered into the URL box. On the web, websites are defined by their domain name. That is the thing I want verified. For EV I also want verification the domain name matches a company that should have that name. But the core thing is a domain name.
You can imagine inventing a more systematic approach to assigning names, but it would be like using scientific names for animals instead of common names. Domain names serve this purpose already. What we really want is to document popular usage.
One systematic approach to tracking popular usage might be to treat this like creating a dictionary. However the dictionary compilers are always going to lag popular usage. This is why Yahoo's directory-based approach lost out to Google. The closest thing we have now is Wikipedia and Google gets that data via crawling.
I guess you could say that human languages are not entirely secure due to being a bit nebulous, but it's the best we have for humans referring to things they remember. If you want to be precise, you need to remember, record, or communicate the domain name.
Leaving aside the UX, I think there's also some value in providing legal authorities with a smoking gun in situations where phishing or other illegal activity does occur using a domain with a EV certificate. The extent to which current EV certs serve that purpose is debatable, but the idea is has merit.
Simply having an e-mail on one of these domains implies access to e.g. free GitHub accounts.
We could have something akin to .bank.uk for banking purposes (you are only allowed go have one if you have a banking license).
The domain name system already handles this by enforcing uniqueness and leveraging the market.
Banks which have the same name as other banks should change their name, but we should tie EVs for banks to existing financial system institutions. For example, most banks in the US have an FDIC number, so our EV validators in the US can tie a bank to it's FDIC registration, and the user can cross-reference their bank with that as well. Basically if I'm a bank customer, I should have a unique identifier on my check or debit card which can be cross-referenced with the EV cert.
The vast majority of consumers are not going to lookup an FDIC number, and even if they did, it is still not optimal since banks regularly merge which would cause confusion.
As you point out, there are plenty of real businesses with names similar to each other. And yet, they all manage to do business with their customers. How does it work? Because customers use more than just a name to recognize a business.
IMO this is a good example of how the goalposts have been moved on EV certs over time. They were never intended to solve name uniqueness globally, so IMO it’s silly to complain that they don’t.
Why don’t we include, in the EV cert, enough info to uniquely identify a business? E.g. the jurisdiction of business registration + the business registration number?
What if browsers were designed such that for each website, over HTTPS or not, the first X times you visit it, the browser forces you to review the relevant WHOIS and/or certificate info in a modal? And also force you to review the certificate if the certificate has been renewed/replaced?
I’m a security-conscious, technically savvy user of the internet, and I’m neither convinced I would put up with this for more than a day before disabling it or that it would improve my security if I were to try. I’m pretty confident my eyes would just start glazing over the 5th time I scrolled through cert metadata.
You also don't need to show all cert metadata; just enough to be meaningful to the user. I believe that stuff like certificate signature, public key, and hash don't need to be shown to the user in such a modal dialog; they could be automatically checked against certificate transparency logs.
What you want to show to the user in such as modal is stuff like:
- entity name
- business registration jurisdiction
- business registration number
The modal should also have clear wordings in big letters of what a certificate actually means, namely, that the communication with the server is safe against eavesdropping and forgery, but that it's the user's responsibility to make sure the server is not an imposter - e.g. similar name or same name but registered in a different jurisdiction than the legitimate entity.
It's a lot about education, awareness, and timely reminders.
The alternative, which is to hide any indication of EV from the user, seems to be throwing up our hands and just assume users are always dumb and lazy. In that case, why bother with, not just EV, but any certificate at all?
But you have a latent expectation that the store is known to local authorities, who will be able to investigate a crime if that business commits one.
The information in an EV is not for consumer inspection up front, it is a paper trail for investigations to follow after the fact. The optional provision of this paper trail is a signifier to the consumer that this business intends to operate responsibly. Just like going through the trouble of setting up a store front is more trustworthy than pulling a truck full of inventory up to the curb.
What browsers could do better is leverage the EV info for consumers. For example, show a "report a problem with this business" button that connects the consumer with the relevant authorities and/or Better Business Bureau in the locality where that company operates. The EV supplies the legal company name and its locality of origin.
I was surprised how easy it was to get an EV cert. The validators work from an offshore call-center and use sites like whitepages.com to lookup the business. They then call the number listed (you could have updated the listing just before). When they call you simply have to say "I am ... and my position is X at Y company. Then hand the phone to someone else who says something similar". There was no individual identity verification.
No CA should make it this easy. Any CA that keeps it easy should just be dealt with by the CA/Browser Forum.
I prefer technology to deal with technical issues and present a relatively formal interface to the end user. Human politics are complex. Any interface that abstracts human politics and legal issues will have to deal with so many corner cases that its interface will either be unreliable or more complex than URLs.
In fact, phone numbers are absolutely the equivalent of domains, and the equivalent of IP addresses in the telephone system is IMSI (I think). You can transfer phone numbers between subscribers, and so the number that you thought was going to your bank could actually some day go somewhere completely different.
In any case, I don't really understand what point you're trying to make. For the phone system we assume the phone company will route our call correctly. Sometimes they don't! Over the years I've seen a number of anecdotes where someone called a number and was connected to the completely wrong person, and when they tried a second time it worked. At least the DNS system allows critical sites like banks to use features like certificate pinning if they're afraid of hackers intercepting their domain and having a DV cert issued by a trusted root.
I agree.
Chrome mailing list announcement: https://groups.google.com/a/chromium.org/forum/#!topic/secur...
Firefox mailing list announcement: https://groups.google.com/forum/#!topic/firefox-dev/6wAg_Ppn...
Firefox bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1572936
Firefox, is, of course, following the monopoly lead.
[1]HTTPS encryption itself doesn't meaningfully require public key infrastructure, it's just that without PKI, you don't know who sent the encrypted traffic. Since domains are terrible "identities" and it's common for large organizations to use many of them that sound similar to scam domains, domain validation really doesn't tell anyone anything about whether or not they're talking to a trustworthy entity.
[2]Basically Google said it wants to "invent" EV certs here, late last year: https://www.wired.com/story/google-wants-to-kill-the-url/
It is trivial to get an EV cert for a company that has the same name as a trustworthy entity[0]. There is nothing in the design of EV that prevents this, and name collisions between corporate entities are common and acceptable practice[1].
[1] Trademarks are a different matter, but getting an EV cert for a company that has the same incorporated name as a different company in a different state is completely legal.
It is legal. But it's also much more easily traced (even through various shell companies as process agents want to get paid), which compared to the way most crime works on the internet is infinitely more risky for the perpetrator.
Also, companies like banks regular scour business records for similarly named businesses, which means the window for fraud is smaller. I'm not surprised that someone would find it easy to spoof Stripe, but let's see how long they manage to spoof PayPal or Bank of America. If they don't already, EV certificates should issue only after the named entity has existed for N months (or years).
can't they also scour the certificate transparency logs as well? I'd imagine that's easier and more reliable than scouring the public records of hundreds or thousands of jurisdictions.
When SSL first came out there was a heavy focus on informing the public to check for the padlock; that if they were worried about fraud then checking for the padlock was a concrete step they could take to help reassure themselves. But there was never a similar campaign regarding EV certs. There were attempts, but they were short-lived and not nearly as aggressive. Partly that's because the messaging was more difficult, but it could have been done.
Google could have put more effort behind it. But they weren't interested, partly because as someone else mentioned they have their own ideas about how to move forward, ideas that just happen to fit in better with Google's commercial interests. Some of those ideas are reasonable, but again this isn't an either-or situation. They're making it either-or.
There’s a separate rule that you can’t name a new bank “America” or “USA” or anything like that. The existing ones are grandfathered but no new ones are allowed.
Unfortunately, the only meaningful form of identity confirmation we have is being railroaded away using one-off examples of imperfections that can be fixed fairly trivially, and which have never been effectively used maliciously.
you've got someone to sue if criminal activity happened which is already miles better than the current situation.
Which is exactly why name collision are not actually a failing of EV and why the Stripe EV trick, while cute, did not demonstrate anything meaningful about the utility of EV certs.
EV was never intended to be a perfect phishing prophylactic, so I can't understand why people seem to get so much mileage out of pointing out that EV's can't prevent all phishing.
What EV certs do better than DVs is provide a paper trail for sites that commit crimes. To get that name-colliding Stripe EV cert, Ian had to use his real identity to create a company; he even helpfully links to the record! That's going to make it a bit easier for law enforcement to track him down if they are investigating his website.
Plus this article explains, in great detail, why EV didn't work/couldn't work. Google didn't cause that, nor did Apple. Researchers have been creating examples of EV's problems for years and the evidence has been mounting against them.
EV has issues, which the article exaggerates (Troy Hunt has amazingly good services, but absolutely terrible opinions), whilst failing to recognize that the alternative is completely useless.
no it's not?
The title is referencing the author's post on EV certs being dead after the change in Safari and the article quotes Google, Mozilla and Apple's reasoning for the change. Your argument should be with those statements, not a narrative you're forcing on the events.
The vast majority of examples of EV "problems" are people who misconstrue what EV is supposed to do, and then prove it can't do that thing. For example, EV was never intended to guarantee globally unique company names, so demonstrating a name collision does not actually show a problem with EV.
I'm not really sure why you're including Microsoft in here either, but I'm a lot less familiar with Microsoft's various product offerings so maybe there is some reason why they care about the public identity business.
Note here that using the mobile app is in no way any form of lock-in, because the exact same app will exist for Android too, and it's free, so there's no barrier to switching platforms.
In other words, HTTPS encryption meaningfully requires some kind of public key infrastructure.
Without some kind of infrastructure, the whole system falls to any active attacker --- and almost all modern attackers in the TLS threat model are active.
And even for well-known domains, https://www.xn--80ak6aa92e.com/ (currently still works in Firefox) is an excellent example of why domain validation remains completely useless.
[1] https://money.cnn.com/2017/09/20/technology/business/equifax...
This is one of the older controversies on m.d.s.policy, for whatever it's worth to you.
I don't really care where you or anyone else comes down on this, as long as we all agree that you can't just jettison certificates and let HTTPS "just provide encryption", which is a common HN refrain and is clearly unsound reasoning.
The CA provides multi perspective check from servers connected to internet backbone, where network hijack is harder than at cafe wifi AP.
If Microsoft included a self-signed cert in my Windows install for itself, I would know my communications with Microsoft came from whoever made my Windows operating system. Meanwhile, with PKI, dozens of companies can technically generate certificates for microsoft.com and we're just all hoping none of them do it without getting caught.
A rogue/compromised CA will be caught by certificate transparency and distrusted.
Also, as 'tptacek noted, you haven't explained how to securely use self signed certs to protect against attacker at the WiFi AP, which is a very accessible kind of attack (compared to compromising a CA, a registrar, a datacenter or internet backbone traffic).
Those changes are being largely driven by Google/Mozilla/etc, via enforcement around what CAs must do in order to be part of the root of trust.
Switching to self-signed certs doesn’t remove any problems. With current PKI, dozens of companies can generate certificates for my website which will be trusted by user browsers. Without PKI, literally anyone can generate a self-signed cert for my website, and there’s no concept of which certs are valid, unless somehow everybody finds a way to share which certs are theirs (and solving that is generally called “PKI”).
EV doesn’t allow self-signed certs to work either, or viably replace DV certs for any threat models, because it’s just as easy to register a similar-sounding company name as to register a similar-looking domain name. Arguably it’s easier, because you can actually register exactly the same name, just in a different jurisdiction.
I am not saying issuing self-signed certs are great, merely that CAs do not meaningfully improve on them if domain validation is all we have, because domain validation doesn't tell you a heck of a lot.
As you said in another response, the CA system has problems. EV, at least, represents something useful when issued by a CA and solves a real problem. And the problems with EV Troy complains about are all fixable.
How is it that this still works in Firefox? It's been fixed for years in all other major browsers. I'm seriously shocked that Firefox still allows IDN homograph attacks.
TLS protects you from active attacker at your internet cafe wifi or small ISP or not-tier1 country's ministry of propaganda.
If the network between multiple aws/gcp/azure regions where e.g. let's encrypt's acme servers are deployed and the server you're talking to is hijacked, TLS doesn't help because hijacker can get valid certificate.
Fundamentally I believe security doesn't scale, and that something you can automate is inherently inadequate for security. Which is perhaps why I have so many security problems with Google's approach.
It really does though, because without PKI a MitM attack is totally undetectable. That means any ISP can tamper with and read all your stuff. Any public WiFi can trivially read all traffic over the wire. Any temporary and intermittent manipulation of DNS comes with immediate compromise. And on a LAN, that affects IP or name resolution is compromised.
The only thing you would defend against are constrained infrastructure managers (those who could MitM but don't have the resources) and people sniffing the line but not able / willing to modify data on the line. That would be really covert agencies and people with a WiFi sniffer.
I agree that for PKI in general, something like EV would be great. But that is a lot more useful for something like S/MIME or a replacement of PGP, not in the case of HTTPS.
If true, that says more about the usefulness of PKI, than the usefulness of EV certs.
> And the only reason it's being pushed out is because Google doesn't like it and hence Chrome has been retiring it.
Google is far from the only people that don't like it, and far from the only ones pushing for their abandonment. They're fundamentally broken, in my view. And it's worth noting that Google/Chrome is just following the trend of not using them; are they really driving anything here?
This allows EV to have real benefits without requiring any user alertness.
This largely misses the point. PKI infrastructure allows me to click a link from a trusted webpage (like a search engine which removes malicious content) to an unknown website and be reasonably sure that I am talking to same unknown web site that the search engine looked at. It's right there in the name "web" - trusted sites refer to other sites by domain, so domains are what we need to validate.
With Google removing https:// from the URL and EV being gone, I don't even know what to trust anymore.
Edit: I see, it says it was revoked. Well that makes sense:
> Edit (April 29th, 2018): This site no longer uses an EV certificate. Comodo arbitrarily revoked — without any notice — the first certificate, saying this site was made with the intent to mislead. GoDaddy issued us a new one on 04/11/2018, but revoked it later that day, stating that the site was fraudulent.
So OBVIOUSLY the CAs are trying (maybe not as hard as we'd hope) to make sure EV is used responsibly, so why kill EV? Why not just improve the process a little bit more to make it unlikely to give an EV cert that clearly intends to mislead?
> It is notable that neither company believes they mis-issued the certificate.
What? They clearly revoked both and specified the reason, so does that not make the mis-issuance implicit?
https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-...
Comodo has told me that they would give me a new certificate if I wanted. Unfortunately, tax complications in Kentucky mean the legal entity no longer exists. Feel free to replicate it, though :)
The definition of "mis-issuance" has some contention, but generally it means that the guidelines for issuing the certificate were violated (Baseline Requirements, EVGLs, etc). No guidelines/policies were violated for those certificates.
The point of an EV is that it ties TLS authentication back to a legal identity. Ian even helpfully points out that that the two "Stripe" companies, his and the famous payment company, have different corporate filings. He even links to them!
I would argue that this demonstrates, not disproves, the value of EV. A DV cert would not be traceable to any corporate filing at all.
But that doesn't matter. The whole point of EV was that users would see the name in the address bar and trust it. If the model requires users to click through and read the details of the corporate filings, then EV was already a failure before it began.
This is not the point of EV. That's what I'm trying to say here.
It's obvious this would never be 100% reliable because sometimes the corporation has a different (lesser known) name from the popular product, and sometimes company names are similar.
The idea that EV only works if consumers 100% recognize and trust every possible green name is a strawman that was propped up to be knocked down.
And since CAs wanted the EV cash cow, they implemented CT and other improvements, and once they had the code, they had little reason to object against applying the same requirement to regular certificates.
Another advantage is that when my bank requires me to enter a verified-by-visa password on lookslikephishingbutreallyismybank.com, I can actually verify (with a reasonable degree of certainty) who the site belongs to - even if they could, attackers generally won't go through the effort of getting a similar name. But that's a power user feature.
On the contrary, we should just push for extended validation on all certificates. Whether they come with a fancy UI or not.
Because if we are on the topic of https UI effectiveness, then I'm pretty sure everything we have right now is doing a horrible job and could be removed with much the same tenuous reasoning.
I remember that someone had successfully got an extended certificate for "Stripe, Inc".
Things like certificate transparency log monitoring seems better than EV to improve security.
That's before you get to the UI failures, where phishers can trivially get that lock for their microssoft.com domains.
There's already a lot of things being done to improve the situation. Honest question: Are you aware of them? Do you know Certificate Transparency? Have you followed the intense discussion about Dark Matter? Do you know what the Baseline Requirements are? Do you know how Webauthn prevents Phishing?
This is analogous to how a fraud is discouraged in physical stores. A street address and business license won't prevent a store from ripping you off. But it gives you plenty of info to pursue a complaint if it happens.
The reason why "Stripe, Inc." is interesting is because it disproves the whole claim that users can trust the business name displayed, because they can't. It doesn't matter if the CA has a paper trail for the EV cert, because nobody's saying people will use EV certs for large-scale phishing attacks (users don't even notice its absence to begin with so there's no point). But since you can't trust the business name, it means EV is actually an attack vector for spearfishing. Pick a single high-value target, get a misleading EV cert, get them on that site. EV is now a significant negative.
The only people who made this claim, did it so they could attack it.
The only claim of the EV system is that the display name matches a real legal entity, which is not the same thing as being consumer-recognizable.
The intent with EV was that the presence of its UI element--regardless of what it said--would confer trust. The idea does not rely on users recognizing the company name any more than trust in physical stores relies on users memorizing street addresses.
The concept is that a legit company would opt to tie its online presence back to its legal entity (via an EV cert), but a scam would not because doing so would take more effort and make it harder to escape.
Again: this is analogous to the effort that it takes to set up a physical store. You can buy things off the back of a truck, but everyone knows that is sketchy. You don't know where that stuff came from, and you have no recourse once the truck drives away.
Setting up a store is a lot harder than driving up a truck--a company has to establish a legal presence in the jurisdiction, sign a lease, get a business license, comply with all sorts of regulations, pay taxes, etc. But they go through that effort because doing so confers trust. It is this system that is behind the social convention that it's ok to walk into a new store and hand them your credit card to buy something.
The goal of EV, of the CA system in general, was to try to create a similar set of trust signifiers and conventions online.
I don't see how you can say that.
If I go to paypal.com and see "Joe's Pizza Shack" in the green text, there's no way I'm going to trust it.
If a phisher is capable of legitimately acquiring a certificate that says "Stripe, Inc." just as they could one that says "Joe's Pizza Shack", then the presence of the green text means nothing more than "someone was convinced to pay money for green text", and it certainly doesn't mean I'm talking to the company I thought I was.
And the ability to get a legitimate certificate saying "Stripe, Inc." means that EV can aid phishing attacks, because the existence of the green text is supposed to trump all other trust indicators ("is paypalcares.com legitimate? It's got the green 'PayPal, Inc.' text, it must be!").
Which is to say, users don't notice if the green text is gone, meaning it has no benefit, and users may trust the green text over other warning signs, meaning the ability to successfully spoof another company's green text makes EV an attack vector rather than a defense.
It means someone was willing to pay money and publicly confirm their legal identity.
I think you under-appreciate the implications of that, and are overly focused on the mechanics of phishing (which is just one aspect of security). Even if EV certs are not any better than DV at preventing phishing, they're better for investigating phishing.
If that worked well, over time it would create a deterrence around using EV for crimes, which would not be perfect, but would create an improvement in trust.
But it doesn't work well. So to be clear, I'm explaining why EV certs exist--what they are actually for. I'm not claiming the system works great; in fact I think it's pretty crappy how poorly it's implemented by the browsers. As you note elsewhere, it's hard to see and do anything with the extra info in an EV cert. And I have to wonder why that is.
Except general phishing sites won't use them, which means they won't do anything for investigating phishing. There's no need for phishing sites to use them since users don't notice.
The only real scenario where they'd be used is in a spearfishing scenario where it's worth the risk in order to snag a high-value target, especially because it's a lot less likely that your misleading EV cert will be captured by investigators (once you're done with that one target, take down the site before anyone can look into it).
One of the worst experiences I had was getting docs notarized just to have the CA turn around and ask me to send them a list of notaries in my area so they could call the one I used.
The whole system is terrible and the margins are so huge that nothing will ever be fixed unless the CAs are forced to come up with something better.
Because he has personally been on the front line of the debate, been told by lots of people and entities with power in the relevant domain that he's wrong, and events are proving him right, at least in terms of his predictions about what would happen. Taking a bit of a victory lap is only human. I thought he was suitably discreet about it.
Separately, I think it there is improvement here, which is that the system is no longer claiming to be securing an element of the connection which it isn't really securing. Sometimes if you want to make progress you have to clear the fake solutions out of the way that are just sitting there creating the illusion the problem is solved, so that nobody tries a real solution. Personally I'd say that what we have right now does a good job of being what it is, it's just that there's a mismatch between what it is and what people thinks it is. This makes room for other potentially better solutions by helping to resolve that mismatch.
(In a nutshell, the system is good at asserting that you are speaking to someone who has convinced the world that they are capable of serving web requests issued using a particular domain name (I tried to write that carefully), and that nobody in the middle of that connection can intercept or modify the contents. We can now clearly see a problem in how we connect that legal entity to the domain name, without EV certificates sitting there pretending to solve that problem.)
Why? In the m1cros0ft.com example, you just need one domain, and you can send a phishing link out to millions of addresses.
> And unfortunately, a whole generation of computer illiterate users believe that lock means the site is legit.
That's exactly why EV doesn't help, because those users _also_ don't know that the absence of green is supposed to carry semantic meaning. In fact, those users largely don't know or care what a URL is in the first place.
HTTPS everywhere is unequivocally a good thing. I can (and do) personally run websites that have active user accounts precisely because of LetsEncrypt; it would be a terrible idea to train my users that they should type a password into a form that's submitted over HTTP. But I don't have a budget to pay rent-seeking CAs for certificates whose value is based on artificial scarcity.
Phishers weren't using SSL before HTTPS Everywhere much because it didn't matter. Most users (and in particular, unsophisticated users that are more likely to fall for phishing attempts) who type in passwords by hand aren't going to notice the lack of a padlock. We needed HTTPS Everywhere before browsers could meaningfully penalize the HTTP experience, otherwise they'd be penalizing the majority of sites on the internet. And we can't have HTTPS Everywhere unless SSL certificates are easy to obtain.
Which is to say, the fact that phishers can obtain a LE cert today for their phishing site and therefore not have the "Not Secure" indicator is not meaningfully different from the old days where they'd use HTTP and not have the small green padlock that most people don't notice.
Since then the market has changed a lot. E.g. Letsencrypt happened and several companies, including amazon, now offer very convenient ways of getting certificates. So, last week the process was as follows: 1) I created anew certificate in the region where I needed it. 2) after waiting for it to deploy, I selected it from a drop down on the ALB where it was needed. End of story. It will take care about renewal, adds no extra cost, and requires no fiddling with text files.
I, for one, always make sure my bank has EV before I enter the password. the fact that most people don't doesn't change the fact that it does provide additional trust for those who are aware. security isn't all or nothing.
the second use case is when you first visit a website, which potentially asks for credit card number or anything sensitive, it does improve your trust and reduces the friction with lesser known websites. of course PayPal, as a well known and trusted website doesn't need it - nobody is asking themselves if they should trust PayPal. again, it's probably not a security boundary, and it's probably not impossible to generate bogus ev certs, it's better than nothing.
And yet, there are no reports of people thinking their paypal is untrusted. Nor did paypal decide to roll out EV everywhere because they were losing users.
[1] https://www.troyhunt.com/paypals-beautiful-demonstration-of-...
edit: Claimed that EV differed based on location, but it was based on browser.
The real security here isn't the cert, it's the fact that I use a password manager and it will refuse to enter my password if I'm not on the right site. If I pop open 1Password and it doesn't offer me my bank login, then clearly I'm not on my bank's website.
Code Signing will still be $175 too expensive and still work just as they have.
Register a company, buy an EV cert, sign your malware. The only barrier is $ because there’s no limit on creating cheap companies.
The whole “trust” industry is ripe for disruption if someone can get Microsoft on board.
Also, EV certificates are for bypassing reputation checks for smartscreen[1], not for UAC dialogs. If the user has smartscreen disabled, there's no difference.
[1] https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-sma...
Anyway letsencrypt already serves 80% of market. So it's already too big to fail, I don't see much difference between 80% and 100%. But dozens of random CA roots in my browser do bother me.
The difference is all the big websites still pay for certs, so if LE is distrusted then your bank will still work, google.com will still work, apple.com will still work, etc.
> Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended (see Further Reading in the Chromium document). Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection.
Chrome has never tested a verification marker that resembles ANY of the common standards for verification used on Twitter, Whatsapp, Facebook, Apple's App Store or Google Play.
No research into better indicators has been done because Google do not wish to do research into better indicators. Decisions are:
- made by one individual who believes users should be able to detect bad sites because they "don't look right"
- supported by another person who thinks users can use DNS to decider whether sites are real. Ask a regular web user, or even an infosec expert to determine which out of "google.im", "google.co.uk" and "withgoogle.com" is actually controlled by Google.
- and further supported by somebody else who thinks a study of IE7's UI:
foo.com VeriSign [US]
Yes UX designed in the mid-2000s, prior to modern verification standards, is sub optimal.
I've suggested Google's UX people investigate better alternatives for years. They're not interested.
The CAs aren't that much better either (being slow to realise how much the market is changing around them) but Google are absolutely not interested in finding out what would be possible with a modern verification UI, or making sure users know who they're connected to.
Browser vendors have tested the efficacy of the current EV indicator, resulting in the current action.
If you feel that testing an alternative indicator consistent with other platforms is a good idea, then perhaps that's where the CAs should start their research.
>>> But, didn't browser vendors do that
>> No, browser vendors have not tested verification markers that are consistent with other platforms.
> That's not what I asked, that's a straw man.
Doesn't seem like much of a straw man to me. Investigating whether browser security UX helps people understand what they're connecting to logically includes looking at designs other than the current one.
> then perhaps that's where the CAs should start their research.
Yes. And browsers too.