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/
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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 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.
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).
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.
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).
The domain name system already handles this by enforcing uniqueness and leveraging the market.
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.
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.)
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.
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.
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.)
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.
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.
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.
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.
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?
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.
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.
> 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.
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
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.
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.