It's actually kind of unfortunate, as in some ways an organization's name is a much more meaningful expression of identity than a domain name is. When I visit the website for my bank, I don't really care that the entity I'm communicating with owns "mybank.com". What I, and I suspect most people, are really concerned with is that the entity they're communicating with is the same physical, real-world organization they opened a bank account with in the past.
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.
The names that people are familiar with come from branding and publicity - that is, advertising, news, social media, and so on. This affects the web pages that search engines crawl, what users search for, and also which websites rank higher. I'm not sure how someone would do better than search engines? Searching for the company you're looking for usually works.
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.
Yes, search engines do serve a similar purpose. It's not a very rigorous solution though, and there are plenty of ways to get to a website that don't involve going through a search engine.
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.
Near collisions of logos (i.e. off by a few pixels) would register as different. You don't want to rely on trademark suits to kill those logos, as it takes a lot less effort to create a logo than it does to sue it out of existence.
Yes, displaying "Stripe (The Real One)" would work pretty well too. Nobody (that I have seen) has proposed any way to summarize the asinine world of trademarks into either.
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/)
Hi Ian, I pointed my job out in the first sentence of my first reply on this page.
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.
Who decides the categories? For example, what would the category say next to a cert for Amazon? Google? Netflix? What would the cert say for Slack (who pivoted from one industry to another)?
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.
The applicant chooses the field of endeavour in their trademark they the applicant think best reflects their identity.
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.
So Stripe picks “financial services”, and then I set up fake-stripe and I pick... “online transactions”?
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.
Trademarks are applicable across many named domains - the proposal is for the applicant to pick one for display purposes, however they are not limited to having a monopoly on one field of endeavor.
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.
Fixing EV would mostly entail making it a more exclusive club (not an "I have $400 to blow" club, but a "this is a household name" club) and shoring up the requirements to get one. Far from an insurmountable task. Everyone should not have an EV, but everyone should know that if you're doing business with a bank or a major store they should have an EV.
There's no reason EV policy can't be modified to also enforce uniqueness. In fact, that's what I'd expect if we're only giving EVs to household names.
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.
How do you decide which one needs to change its name? There's no objective measure for which is 'larger'.
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.
I don't think we really care, do we? I'm not really worried that I connected to First Bank rather than Second Bank, since both are legitimate banks; what I want is to ensure that I didn't accidentally connect to Second Bannk, the local fraud shop. "Is this site controlled by a FDIC-registered organization" is probably good enough™.
Why do EVs need to solve a problem that is already solved offline?
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?
When issuing the EV cert, they don't actually validate any of that so it is of questionable utility.
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.
Then the problem isn’t really with the EV cert itself, no?
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?
Who are these hypothetical users who are going to conduct a thorough review of Whois/cert data the first $n times they go to a site?
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.
My hypothesis is that users just need to have an in-your-face reminder that they are venturing into uncharted territory whenever an unseen domain and/or certificate comes up. The "X" in my "first X times" could be as low as 1.
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
That's the kind of info that the CA ought to validate diligently. That's also the kind of info that people use to validate the identity of businesses in the physical world.
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?
Do you look at the business license of every store you walk into? Probably not.
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.
URL <=> Brand relationships are purely human politics.
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.
It does not matter. Main point is: "reliance on the absence of a positive visual indicator was simply never a good idea in the first place".
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.
Sure, but a few years ago the same was true of the visual indicators for plain DV https. Browsers responded with an effort to increase adoption of DV certs to the point where positive indicators for encrypted connections could be replaced by negative indicators for unencrypted connections. Could a similar approach not also work with EV certs?
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.)
That would be a pretty decent approach, but an EV cert does not assert that:
> 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.
- 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]
This has been suggested to Google, who indicated they were not interested.
> 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?
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.
Sure. How do you know the URL is who you think it is? How do I know if withgoogle.com is Google or not? If I do know who I'm communicating with, why do I care about the domain it's on?
Thought experiment: Let's say you decide to phone someone who works for the bank. How do you know the phone number you have is correct? What if phone numbers were perceived to be "dynamic" -- subject to change at any time, even by the hour, without notice to you -- such that you could not rely on a consistent, stable phone number for any reasonable length of time. What if, instead, you would need to look up the number every time you make a call? What if phone numbers were thought to be too difficult for people to remember, so someone decided that all you needed was the name of the person at the bank. (Even though that name may belong to many different people across the world.) What if someone further decided that the lookup should handled by someone else. No need for you to be involved in that process. How could you be sure you were calling the intended bank employee?
It sounds like you're describing IP addresses, except people don't type in IP addresses to go to their bank. They type in domains.
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.
Ok, then whatever the equivalent is for landlines. I don't know how telephone numbers are assigned to particular physical lines, but however that's done, it can be changed.
So, a landline phone number that theoretically changes so frequently and without notice to you such that you are encouraged to keep looking it up again everyday. Except you are not expected to perform or monitor that process. Instead it is automated and hidden from you. Imagine this creates risk of fraud by someone pretending to be the bank employee, so then you rely on a third party to "validate" the number you obtain for the bank employee.
I mean, you just described mobile numbers. If someone calls my cell phone, the phone system has to figure out what tower I'm connected to and therefore how to reach me. That's roughly equivalent to figuring out what IP address the domain should resolve to right now.
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.
The irritating thing is that EV is the closest thing to a useful thing PKI can provide[1]. And the only reason it's being pushed out is because Google doesn't like it and hence Chrome has been retiring it. Google's previously indicated it essentially wants to build it's own system[2] that is... effectively EV. So this is probably the death of a problematic but fixable open system which will be replaced by a proprietary Google-owned one.
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.
I don't understand the odd focus on Google/Chrome here. Apple got rid of EV long before anyone else (on mobile Safari, then later MacOS Safari). Google is following Apple.
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.
Apple, Google, Microsoft, all dislike EV for the same reason: because it is a decentralized tool for establishing identity. Identity is something they prefer to own proprietarily because a) they trust themselves more than anyone else, and b) it is lucrative.
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.
Why do you claim Apple dislikes a decentralized tool for establishing identity? No part of Apple's business is even remotely related to what EV certs do, and the closest they come to "identity" in general is the recently-announced "Sign In with Apple", which is personal identity for use with other services, not a public identity or anything used for a company. Apple cares about this purely for user experience, nothing else.
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.
You don't think Apple cares whether you feel safer downloading the Bank of America iOS app from their carefully curated App Store, instead of navigating to bankofamerica.com in mobile Safari?
Correct. Apple doesn't make money off of your interaction with BofA either way. They care that you have the best experience and continue to use their platform, but whether you use bankofamerica.com versus a mobile app, it doesn't matter.
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.
The article is about Chrome, which is a monopoly-positioned product, making a change, upon where the author has stated that as such, EV is really dead. I am not sure why talking about Chrome here would be an "odd focus". When the dominant party does something, it means a lot more than when a minority party does something.
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.
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 Safari change was mentioned in past tense (a year ago) as was Apple's statement about it, and this article is about the change in Chrome and Firefox.
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
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 it fails to be useful without a way to tie it to a brick-and-mortar entity, aka, EV. Which is my point. That was exactly what PKI could bring to the table.
Either you're not understanding me or I'm not understanding you. I'm making a simpler point: some kind of authentication does indeed have to happen in TLS. Without it, TLS provides essentially no security.
I'm saying in a world where equifaxsecurity2017.com is a real domain, and securityequifax2017.com is a fake one that the real Equifax Twitter account posted[1], domain authentication is not authentication at all. As such, without EV, TLS provides essentially no security, correct.
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.
Your complaint is about phishing. I agree that phishing is too easy. But that concern is orthogonal to (and significantly harder than, both technically and from a policy perspective) reliably encrypting the TLS transport.
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.
You could jettison PKI though. Self-signed certificates would provide as much security after the initial connection. The theory of PKI is that the CAs are providing a source of trust in the identity of the certificate holder, but that is mostly meaningless if domains cannot be meaningfully connected to real businesses and/or people.
How exactly do you think a self-signed certificate addresses this problem? I connect to BANKOFAMERICA.COM. It presents me a self-signed certificate. How do I know if that's BofA's self-signed certificate, or any active attacker's?
How do you know bankofamerica.com is owned by the actual Bank of America? Or that someone didn't use a Cyrillic character in that URL so it looks legitimate and even has a CA-signed cert? Or that one of the more questionable CAs hasn't given someone else a cert for bankofamerica.com.
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.
You keep answering this question with an unrelated question. Like I said: phishing works and is too easy to accomplish. That isn't an answer to the question I just asked you.
You are dismissing the primary issue at hand, which underpins the entire conversation. Phishing is what EV addresses. And if you're not addressing phishing, you're not meaningfully addressing any sort of Internet security whatsoever.
The incoherence of EV as a response to phishing is part of why it's failed. But I'm not talking about EV; I could care less about EV. I'm addressing your (false, increasingly so as thread deepens) claim that HTTPS doesn't require any form of PKI and that users might as well rely on self-signed certificates. Obviously: no.
The self signed cert will need to be rotated from time to time, without being signed by previous cert because e.g. private key was lost or because private key is known to have been compromised. How will your browser, connected to cafe wifi, know that change in self signed cert since last connection is legitimate vs MiTM by wifi AP in cafe?
The CA provides multi perspective check from servers connected to internet backbone, where network hijack is harder than at cafe wifi AP.
The CA system also provides dozens of organizations all over the world to issue certificates for any domain and to hand them out to pretty much anyone.
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.
You haven't answered the question. There are flaws with the CA system, yes. But replacing it with self-signed certificates creates new problems. How do you address them?
There are mitigations in various stages of progress for this, like certificate transparency, CAA records, and the removal of CAs who violate best practices through either malice or stupidity.
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.
Your OS or an app talking to their mothership can and do use cert pinning. What about all the millions of websites?
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).
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 only says you're having a private conversation with a server, not how trustworthy it is. Maybe you're having a private conversation with the devil!
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.
> [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.
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.
> 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).
Adding the word “bank” is problematic on its own as the naming itself is regulated.
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.
>Also, companies like banks regular scour business records for similarly named businesses, which means the window for fraud is smaller
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.
I'm sure they can and do. But it's not an either-or situation. Also, AFAIU, EV certs won't even issue without heightened scrutiny regarding domain name ambiguity.
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.
if you're dealing with a known legal entity that's misleading and has phishing content, you're already in a much better spot than dealing with a random dude that paid for bogus dns in cash and signed with let's encrypt.
you've got someone to sue if criminal activity happened which is already miles better than the current situation.
> There is nothing in the design of EV that prevents this, and name collisions between corporate entities are common and acceptable practice
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.
This is why I used the expression "problematic but fixable". There are issues, sure, but as another commenter pointed out, they're easier to trace, and these are problems that can be fixed. Meanwhile, domain validation is only peripherally better than "no validation at all".
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.
Google wants to be the world's business authentication provider, but without taking on the responsibilities of an EV certificate issuer to the "relying party".
That was kinda my impression. Extended Validation is supposed to be complicated enough that you shouldn't be able to automate it, and Google hates anything that it can't automate.
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.
This is no different to when Microsoft launched their passport services, MS wanted to develop a global register to verify everyone's identity. It didn't work.
The same identity dupe problem highlighted elsewhere re stripe inc registered in Delaware, also exists when it comes to code signing applications on windows.
> [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.
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.
> [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.
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.
> The irritating thing is that EV is the closest thing to a useful thing PKI can provide
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?
I'm pretty disappointed by this. I definitely trust what I see a lot more when I see the legal entity name in the URL through an EV cert. I don't really understand why it's being removed. It's more difficult to get an EV cert because of the additional legal process, and it makes it clear to the user that the website is run by that entity, which is exactly what we want...
With Google removing https:// from the URL and EV being gone, I don't even know what to trust anymore.
I don't have any solutions to your last statement, but one of the problem is that legal name of the entity matching doesn't really mean its the same entiy you think it is - the example ( also in the original page): https://stripe.ian.sh/
When I visit that page I don't see an EV banner in my Chrome, version 76.0.3809.100. It seems like I'm meant to according to the document?
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?
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.
Corporate name collisions are not a problem that EV was intended to solve.
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.
> 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!
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.
> The whole point of EV was that users would see the name in the address bar and trust it.
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.
But it literally is the selling point. If customers aren't expected to see the green text in the status bar and implicitly trust it, then EV has no value whatsoever. Because 0.00000001% of people will actually click through to see anything past the company name. Hell, I don't even have the slightest clue how to see the corporate filings. When I click through to see chase.com's certificate all I know is it's a company "JPMorgan Chase and Co." in NYC and it was issued by something called "Entrust, Inc."
EV had one advantage: It allowed browser vendors to push for improved standards (like Certificate Transparency adoption) with minimal push-back. It's easy to complain about expensive security measures for run-of-the-mill certificates, it's much harder to argue about such measures for special extra-secure ones.
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.
Good riddance, IMO. They never meant much to begin with, the validation procedures were basically "can you pay the fee?", and they only added to user confusion.
I don't understand the glee, schadenfreude even. So because the UI side of things didn't work out, it is an improvement that now all certificates will go back to the "crusty Perl script fetching a side-channel secret from a webserver" method of "validation"?
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 don't understand the glee, schadenfreude even."
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.)
It’s because the existing system is built around greed more than quality identity verification. I wouldn’t be able to verify the identity of someone in (ex:) India and, I assume, it’s just as hard for them to verify mine. Every time I’ve done verification for code signing I’ve dealt with someone who, IMHO, wasn’t qualified to verify my identity.
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 it makes the people who complain about LetsEncrypt go away. EV certs (arguably) provide extremely little value while allowing an industry to extract money for no reason and also publish FUD about LetsEncrypt, which is among the most impactful projects in history for getting humans to use encryption.
The only meaningful impact of LetsEncrypt and HTTPS Everywhere pushes is that now most phishing sites use HTTPS. Since most non-technical users trust the presence of the lock icon (even though they shouldn't), this has been great for phishing sites.
Then again, the phishing problem is that you can get m1cros0ft.com registered. If you can get that one and trick someone, you won. If you can get it and a cert for it (free or not) then you as a phisher win. If you can't get it, then you can't get an LE cert for it either and you lose. Therefore, the LE part is just icing on the cake, not the enabler for scams.
Cost is a barrier to entry, and when you are scamming people, you often have to be able to generate large numbers of scam attempts, as most will fail. A cert costing $70 is a big deal for a scammer, because a scammer may need to get certs for a large number of domains. Therefore, before HTTPS Everywhere, phishers weren't using them much, it added a lot of cost to each attempt. Now, it's a requirement to avoid warnings in browsers, and the certs are free, and hence, all phishers now use HTTPS. And unfortunately, a whole generation of computer illiterate users believe that lock means the site is legit.
> a scammer may need to get certs for a large number of domains.
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.
Maybe EV isn't the answer. But there is opportunity for something else out there, because right now https is not living up to the "authentication" promise when you have Firefox, Chrome et al. kotau to company proxies and all kinds of dubious state CAs in the trust root.
That's before you get to the UI failures, where phishers can trivially get that lock for their microssoft.com domains.
> But there is opportunity for something else out there, because right now https is not living up to the "authentication" promise when you have Firefox, Chrome et al. kotau to company proxies and all kinds of dubious state CAs in the trust root.
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?
There is a security benefit to EV: the paper trail to which the CA attests. That provides a tool that law enforcement can use to track you down if you use your EV-cert-provisioned site to commit a crime. To get an EV cert, you must prove to the CA your identity, portions of which are then encoded in the cert itself.
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.
That's assuming you even get an EV cert though. EV failed because it didn't provide any benefit, as evidenced by sites like PayPal (which you would think is the poster child for EV) ditching it. Because it didn't matter to users if you had an EV cert, you didn't need to get one.
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 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.
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.
> The intent with EV was that the presence of its UI element--regardless of what it said--would confer trust.
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.
> then the presence of the green text means nothing more than "someone was convinced to pay money for green text"
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.
> Even if EV certs are not any better than DV at preventing phishing, they're better for investigating phishing.
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).
I'd rather not go back to the 2000's and earlier method of validation that required faxing in paperwork, then waiting days and days, etc. This is paperwork which could easily be forged, by the way. Finally, after decades, it is simple enough to get TLS that people actually do it.
I just replaced an EV certificate with a free AWS provided one on our website. We jumped through a lot of hoops a few years ago to get our EV certificate. This was a tedious process that involved form filling, credit cards, lots of waiting and poorly documented ways of handling the actual certificates. I actually had to append some text files to that were sent via email to get a valid thing that nginx actually understood, etc. I lost non trivial amounts of time with this. Because it was so tedious, we went for long lived certificates. When we switched to amazon we preserved our investment and uploaded the certificate to AWS and used it on an ALB.
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.
seems like you are completely missing the use case, if you think EV certificates are for frequently visited website.
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.
Paypal is an interesting case [1]. Whether they served an EV-cert differed based on browser. If EV worked, that would mean people who switched browsers would refuse to use paypal.
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.
I, for one, have absolutely no idea if my bank uses EV. Let me check... ok yeah they have it. But I would not have noticed in a million years if they got rid of it.
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.
What about for Windows development? I just ordered one through my company in order to bypass 'untrusted app' dialogs that my non tech savvy users can't figure out.
MS still requires that drivers be signed with an EV cert
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
And it supposedly does help add some SmartScreen reputation, but that system is totally opaque and there is no way to quantify just what the EV cert adds.
This is a change in Chrome, so I doubt it affects windows.
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.
Why do we need multiple CA now? Keep letsencrypt and distrust everyone else. Their business is dead anyway. Domain validation is an automated process and does not require much income to keep working. Just like DNS Roots works without competition.
Because then you'd be centralizing control of certificate validation in a single corporation, and creating a too-big-to-fail CA that can't be distrusted if it screws up for fear of breaking the entire internet.
We will have enough time to switch to the new CA if necessary. And ACME protocol is independent, so software just needs to update some configuration values.
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.
> 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%.
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.
As someone with a direct interest in this (I run https://certsimple.com, a startup that focuses on steamlining the EV verification process), this is predictable but still hilarious:
> 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]
is relevant research (see this article).
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.
As the organisations that stand to benefit financially from selling these indicators, perhaps it's CAs that should invest in the research? CAs seem to constantly point at the browsers as the party responsible for doing that research, but I don't see why.
Totally agreed CAs dropped the ball on research too. It's not an either/or thing: browsers makers need to ensure their security UX helps people understand what they're connecting to and CAs need to do the same and additionally ensure their verification processes are robust.
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.
>>>> browsers makers need to ensure their security UX helps people understand what they're connecting to
>>> 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.
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.