One of our engagements sent users to a site we just made up, and asked for user credentials for a site they had never heard of in order to access cat videos. In most cases, we were given valid domain credentials. I'd bet money a high percentage of those were also banking credentials. What good would an EV cert at the bank do for this?
As well as preventing confused end users from putting their site A credentials into site B, WebAuthn prevents idiots from designing a system on site B that expects the credentials from site A. It just doesn't work, you can't make it work, so you have to go back to the client and say "No, as well as being stupid that's also impossible". So you not only protect the users from the actual security problem you stop engineers building things which incur the problem in the first place.
As another commenter has said, I can't personally tell you the name of any specific website with an EV certificate. I don't know any friends or family who actually check for the presence of correct EV certificates. It's a cool idea and it's made CAs plenty of money, but it's just too subtle of a cue.
I think many people are resistant to the idea that extended validation certificates aren't effective for one or both of two reasons. First, they probably want to actually do something instead of being hopeless, so they consider doing something better than nothing even if it's not ideal. Second, they are reviewing the technical specification and finding it sound, but not grounding it in the reality of how users work.
Part of the argument against them is not just that they're ineffective, but also expensive. It's not unreasonable to simply call it snake oil. The visual cue would need to be significantly more prominent - up to par with the red versus green icons of HTTP and HTTPS, respectively - in order to have a real impact. Users would need to have better training and education to come to expect the extended validation instead of merely feeling more assurance when it's present. The system has insufficient penalty for sites which should have extended validation but only present domain validation, and browser-buyin to the concept is fading.
Right, once OV and EV certificates are effectively removed from browsers, users such as myself will no longer have any tool to help ensure we are interacting with the entity intend to be interacting with. It is kind of like getting a cold call from your credit card company saying their has been suspicious activity and they want me to authenticate my account with personal details. I always call the phone number on the back of my physical credit card to ensure someone isn't scamming me.
Rather than removing EV certificates as a concept, I would love to see some experiments run by browser vendors to see how users can more readily understand who they are interacting with. But instead, the solution seems to be to get rid of the only option since it doesn't work in its current incarnation.
> Part of the argument against them is not just that they're ineffective, but also expensive. It's not unreasonable to simply call it snake oil.
I have a hard time understanding this argument. You can purchase an EV cert for $80 a year from NameCheap. The extra cost is because they have people verify that the company details you have provided are valid and that you are an authorized representative of the company. Any company that is more than a solo founder is going to be in dire straights if $80 a year is too much. I mean, are you even going to find a domain name and hosting for less than $80 a year?
In reality though, I don't think much of anyone other than major email providers and financial institutions really need to worry about EV. If a website doesn't have EV, but uses PayPal, I have no qualms. But if I go to long into Fidelity or PayPal and they couldn't be bothered to spent $100 per year to help me ensure I am actually interacting with them, that says a lot to me. I mean, even my small town NH bank has an EV cert. It just makes sense if you are dealing with finances.
> You can purchase an EV cert for $80 a year from NameCheap
I've been through this a quite few times. The cost of the cert isn't the true cost. If I could pay $80 to Lets Encrypt to have every issued cert be EV, I'd do it just to avoid this bikeshed. Every single time I've done it, the validation process has been extremely painful. I feel like it's made up on the spot by whatever offshore person gets asked to do the validation. Documents accepted last year are suddenly not accepted at renewal time. Being denied because my Australian company doesn't show up on a UK business register for example.
The certificate policy identifier will be 22.214.171.124.2.2 for OV. You have to look at the certificate details to find it.
I looked into it for someone once. Then I watched in amazement as less technical person insisted on OV certificates.
It also drives the cost of phishing attacks up significantly. Sure, you can get a confusing cert issued, but if it requires you to create a new company, it's not going to be used in mass phishing attacks.
And a personal anecdote to back this up: I'm a pretty savvy web user, I've been around for a while and visit lots of websites, and yet if you were to put a gun to my head and tell me I had to name a website that I was confident would have an EV cert, the only site I could possibly name is my bank, and even that I'm not positive about, I just know that banks usually have EV certs.
(just checked, my bank does in fact have an EV cert)
Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?
Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams. It makes sense for security professionals to focus on the lowest hanging fruit, but the result is web in which first time site visits are perilous and uses get no help at all with that.
> The original purpose of an EV cert is to provide a browser UI that tells a first-time visitor that they can trust the website they've landed on. This is a separate goal from TLS in general, which is just supposed to secure the traffic in transit.
This isn't really accurate. Basic TLS (domain validation) provides encryption and authentication - if TLS did not provide authentication in its most basic form, the encryption would not be very secure on its own. Extended validation merely adds further parameters (properties, characteristics, etc) to the server side of the authentication process that already exists in TLS, in combination with administrative work on the part of the certificate authorities.
Then the client provides the UI visual indicators corresponding to the authenticated identity, as you say. But while all of this technically works, most users don't bother with checking it. Security with friction to use doesn't typically provide any security, it just makes you feel like you're doing something.
> Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?
I can trade your flavor of cynicism with my own: certificate authorities don't want TLS certificates to be cheap, so they come up with shiny options such as OV and EV to have something they can upsell.
See what I just did? We can just keep arguing cynically if we'd like, but we don't arrive at any new insight about the actual point. The fact of the matter is that it's largely irrelevant what Google's motivation is, because the efficacy of extended validation (or lack thereof) does not rely on Google (or any other browser's) motivation. And for what it's worth, Google is not the only browser maintainer moving away from EV visual indicators.
> Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams.
This is a fair point. It's definitely true that phishing is not as sexy a problem as "technical" security vulnerabilities, and so gets relatively less attention. But a security mechanism only augments security if it's actually used or adhered to. I'm not debating the technical merits of extended validation. I'm stating that it's ineffective beause it's a technical solution to a social problem. The way to resolve that social problem is through more sophisticated education and training. Or more likely, to re-architect the interface and browsing methodology in a way that obviates phishing entirely. Just because one of those approaches seems out of reach doesn't mean we should settle for EV, which in practice doesn't do anything. The only nontrivial users of EV are banks and financial institutions; these are the same institutions who have completely bought into security questions, inability to paste passwords and draconian password complexity requirements.
> But while all of this technically works, most users don't bother with checking it.
Shouldn't that be a UI problem? But instead of improving the usability and utility of EV and OV cert content, browsers are instead just hiding it.
> I can trade your flavor of cynicism with my own: certificate authorities don't want TLS certificates to be cheap, so they come up with shiny options such as OV and EV to have something they can upsell.
A lot of people do feel this way. The objection to OV and EV certs has a large cultural component. Browser providers don't like CAs in general. Part of it is because most CAs are not as technically savvy. But yes, part of it is: who is going own identity and authentication on the Web? It's a tug of war with real business implications.
What gets lost in the fight is that EV and OV certs are not just stupid scam upsells. Conceptually they are different from DV certs, and contain different content that could be used to solve real problems for users. Sure--anyone can create a company and register it with a CA to generate an EV cert. But doing so leaves a paper trail that is easier for law enforcement to follow than just a DNS entry for a DV cert.
> The way to resolve that social problem is through more sophisticated education and training.
This is not how social problems get solved. We didn't provide sophisticated education and training to help people discern real clothing stores from criminals who will rob you; we used the collective resources of society to create processes and records that help us hold business owners accountable if they use their business to commit crimes.
1. Alice's browser looks up card.example.com and gets some IP address, it connects to this IP address, with TCP, on port 443 the standard HTTPS port.
2. It does a TLS handshake with the server that answers, it sends SNI asking for card.example.com, the server sends a certificate and proof that it owns this certificate (in older setups the proof may be implied but let's not worry about this detail)
3. The browser validates that the proof is correct, that the certificate is acceptable (signatures etcetera) and that the certificate has a Subject Alternative Name matching card.example.com, if anything is wrong it aborts.
4. Otherwise the browser writes the HTTP POST data over the TLS connection to card.example.com, it gets back an HTTP response body, which it processes as normal, for example, the display body may be a 30x series HTTP redirect back to https://example.com/ and that's displayed for Alice.
Now, where in this process did Alice get a chance to verify that her credit card data goes to Bob?
Nowhere. Even if card.example.com has an EV certificate which says the subject's real name was "Bob Limited" that information is meaningless to a web browser and is never displayed for Alice to look at.
Let's suppose we really try hard to help Alice here. When do we show her the "Bob Limited" subject? We only discover it during the HTTPS POST operation, milliseconds before we send her credit card data. Do we... stall everything, and hope Alice can examine the certificate while the transaction waits? Good luck with that, even if Alice is (unlike all normal users) fastidious enough to not just click "Yes, yes, go away and stop bothering me you stupid computer".
EV is not necessary for card.example.com because a) it's not a domain that Alice will visit directly, and b) Bob has out-of-band opportunities to confirm that he wants his application to connect to card.example.com.
EV does not provide better technical security than DV, it provides better information for following up on problems. If Alice thinks Bob ripped her off, she can look at the EV cert on example.com to get the legal name of Bob's business and the locality in which it is incorporated, and file a complaint against him. She doesn't need to know about how Bob processes credit cards to do that.
If Alice is only going to check any of this long afterwards it doesn't need to be part of the X.509 certificates issued for the Web PKI, Alice can check in any number of ways which business it is that she thinks ripped her off.
Of course since she waited until after she was ripped off it may be that it's a company with no practical presence in her country and she can't do anything about it anyway. But EV doesn't make any difference there.
Trying to get an incorrect extended validation certificate would just add to the money and risk involved in the campaign. Since users only rarely even check them, you don't even need to bother with it.
It's an ill-conceived solution to a problem which is intrinsically enabled via poor security education and habits. Expecting users who aren't sufficiently diligent to check for slightly incorrect phishing domains to look for slightly incorrect or non-existent extended validation certificates is silly. That's not a categorically different approach to the problem, it's just more of the same to the left of the domain name.
There are two issues with EV:
1. They are too expensive and hard to get/manage. We need something like Let's Encrypt so that you can submit documentation etc through an open protocol.
2. The UI is not good enough.
Due the reasons above many companies didn't implement EV.
I find it hard to understand why would someone remove EV with no replacement in place. How can I tell if google-domains.tld is a domain/website owned by Google Inc or a random scam website? Even a technical person is unable to tell you because there is no tool(at least I'm not aware of any) except the EV certificates.
The company you're probably thinking of is Alphabet (does your grandmother recognise that name?) but it might be XXVI Holdings, or Google LLC or any of dozens of other subsidiaries created to remove the ability for shareholders to conduct any meaningful oversight. You can buy Alphabet stock with the ticker name GOOG, and maybe it goes up or down, but you get no ability to see whether they're losing money on AI research or gaining money on web searching, that's all now opaque internal information for a private company owned by a different private company that is merely owned by Alphabet, and so it isn't available for you to even think about.
But even though I got sidetracked by a rant, my real point here is that you have no idea what you expected to see in this EV information, so who cares? You thought you wanted "Google Inc" but that doesn't even exist, a scammer could register it, and fool you, whereas the real Google, who don't own this "Google Inc" name couldn't satisfy you. Ludicrous. If you want the company behind Google.com, don't go to Google.some.other.example and hope to somehow check that's the right company, just go to Google.com
No, they wouldn't be able to register Google Inc and most likely not any derivate either like they do with domain names. Setting up a company is not that easy as you might think. EV implemented right would make most(90%) of the scams unfeasible.
>> my real point here is that you have no idea what you expected to see in this EV information, so who cares?
Well, that's one of the issues that I mentioned and it's an UI issue not an EV issue.
>> If you want the company behind Google.com, don't go to Google.some.other.example and hope to somehow check that's the right company, just go to Google.com
Why would I go to google.com if the link I received in my email has a gmail.com, accounts.google.co.uk or mailchip.com/clickAnalytics=google.de ? Google has many domains so why this one would not be legit?
Question for you:
Is this a legit paypal website? How do you know?
In Ian Carroll's EV experiments it cost him $177 and took 48 hours, to create a new company named "Stripe" in the US and get an EV certificate for it.
So, a lot easier than getting tickets to see a popular musical, but not as easy as buying a McDonalds burger. Is that what you had in mind with "not that easy as you might think" ?
Both the US and the UK have a _lot_ of what are called "brass plate" companies, that is the company doesn't really exist in that country at all, it's just a name plate (made of brass usually) on the wall at some cheap lawyer's office. The real owners of the business will usually never have even visited the country, none of their real assets are present, they just have a legal presence to achieve some other purpose. Setting these up costs under $100 each if you know what you're doing.
I would assume that's a real PayPal web site because PayPal are notoriously bad at this stuff and it's the sort of bone-headed thing they'd do. But if my mother asked about it I'd sigh and suggest she tries the actual PayPal.com and see if there's a link to this "prepaid card" idea from their site. That link might be bad too (PayPal are terrible enough at this that they've done idiot things like advertise sites actually run by scammers because they didn't realise those sites weren't theirs...) but it's the best she can really expect to do when dealing with PayPal.
It also drives up the cost of business for small sites significantly. If thats OK, it better have a pretty significant value. And, all the available evidence indicates it doesn't.
The use case for EV is hard, and CAs did not always deliver on the goal. But instead of working on that hard problem of trust on first visit, most security professionals have decided to ignore that problem and pretend that all certs have ever needed to do is secure the wire. Of course EV certs look silly under that line of thinking, but that doesn't mean it's right or complete.
The industry has basically given up on the idea that there is some way to establish trust on first visit. Which is nuts, because we take it for granted in real life that we can just walk into a brick and mortar store and conduct business without getting mugged.
If you want to blame someone, blame the original designers of the current system, who decided certificates had to be a one-size-fits-all solution for both encryption and identity. Also, blame the years and years and years during which people on sites like HN condescendingly insisted that identity was the important part of TLS/SSL, and who more or less said you'd be better off unencrypted than encrypted without ultra-mega-hyper-octuple-verified identity.
In real life it's difficult and expensive for me to rent a brick-and-mortar storefront, cover it with the branding and logos of a trusted company, stock it with real-looking products and employees in uniforms, etc. On the web, it takes five minutes and costs little or no money to produce a good-enough imitation of a trusted company's site. Any attempt to analogize between them will fail because of how much lower the barrier is online. Any attempt to say that it's easy in real life, so it ought to be easy online is based on missing this fundamental fact.
Also, we live in an age where it's profitable to cold-call people on the phone and say "I'm the tax authority and you owe money, buy $500 worth of iTunes gift cards and send them to this address", and where the majority of calls that come to my phone use spoofed caller ID to try to scam me.
"Trust on first visit" is really a monstrously hard problem, and I think you're underestimating that.
I'm not saying it's easy in real life, I'm saying it's largely solved in real life. There is a big difference between those two ideas.
The difficulty was part of how it was solved. In addition to the physical difficulty of setting up a store, businesses have to be registered and licensed by state and local authorities. The purpose of the EV cert (and the OV cert, really) was to tie web trust back to that same regulatory infrastructure. If you have a problem with a site using an EV cert, you can look up the company info in the cert and contact their local authorities.
Except the only way to get what you want using EV is to force literally every site on the internet to go through the EV cert process. Otherwise, somebody's going to go get a "less verified" cert, set up an impostor site and phish people.
Is that really the world you want? Is that the price you're willing to pay to get it?
No it's not. There are a lot of ways to physically sell things without setting up a retail establishment. You can drag a box out onto the sidewalk and sell sunglasses to people; you can host a yard sale, you can set up at a flea market, you use a classified ad or Craigslist, you can sell through MLM, etc. Customers will calibrate their level of trust based on the experience you provide.
Operating a physical retail store (or a bank branch, or a restaurant, etc) carries with it an implicit promise of trust to the customer, and it's a promise that is backed by social and legal conventions.
So there's a range of experiences and implied trust in physical life, and it's fine if there is a range online. Site operators could choose the level of trust they're willing to invest in providing.
> Otherwise, somebody's going to go get a "less verified" cert, set up an impostor site and phish people.
That's only true if browsers make less verified certs look the same as more verified certs, which is what they are doing. It's a self-fulfilling prophecy. Now every site looks like a guy with a box on the sidewalk.
Given that decades of user research overwhelmingly indicates that the average web user does not understand the components of the browser URL bar, and in many cases those users are completely unaware there even is useful information there, I'm going to bow out of this, because you're now into territory where you need to forcibly educate every single person on earth to understand the URL bar.
(and you're "only" now requiring that every single person who will ever do business of any sort must pay up for an EV cert, but that's actually less of a problem than trying to force people to understand what an EV cert is and how to tell if a site has one)
I think people have just developed a weird blindness about the possibilities of user interface in browsers. There's no reason browsers could not have created all sorts of interesting user experiences with the validated business information in EV and OV certs.
And the whole point of encryption is you think there's a MITM, so if you are using a scheme that doesn't stop MITM, why bother encrypt at all? Just bank the simplicity and performance savings and don't do it.
That seems to be the bulk of the point he's making, EV certs are dead because, especially on Mobile, you can't even tell they are there. He doesn't really, in my mind, support the case that EV certs never were worth anything. I definitely liked to see them when I went to my banks and the like. But I'll admit that I don't remember which ones had them and which didn't, other than that I expected my financial institutions to have them.
This is a core point in the article too that you've glossed over: no one knows which websites must have EV information other than a general "hope my bank has one". EV certificates are useless not just because the browsers are dropping them, the browsers are dropping marks for EV certificates because they are useless for actual security.
They were an interesting attempt at security, but like the "take your shoes off at the airport", it only really helped you from maybe blowing up your own foot, tops. Ultimately the only thing that EV certificates were doing was lining the pockets of security theater predators, because despite "reports" they've never really meant anything to the average consumer and most consumers never learned how/where to look for them except sometimes "maybe my bank should have one, I don't know?"
People only notice when it is there.
not really. there's nothing preventing an attacker from creating a legal entity with the same name and legitimately getting a EV certificate.
The reality is that good security doesn't scale. If an entity starts specifying a reasonable list of certificates it has directly verified are the trustworthy well-known entities people expect, you have a good trust system. Once you start throwing in an automatically-verifiable system where everyone should be able to participate, phishing is going to happen.
As much as Let's Encrypt helped encrypt the web for free, it also guaranteed that convincingly phishing the web is also free. Making a legal entity and going through the EV process is a level of frustration that isn't easy to handle repeatedly, and very few checks would be needed to be added to EV to make it near impossible for an entity to rebrand and reappear after being banned for misusing it's certificate. Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system working as designed.
The only way we are going to ever ensure your bank site can't be imitated by some kid in their garage is going to be to create a system that a kid in their garage can't participate in. And the closest thing to that is EV.
Comodo has apologized for incorrectly revoking the certificate for stripe.ian.sh and offered a new EV cert.
In fact, many browser security developers would disagree with your assessment:
Browser security developers concern themselves with arcane exploits of sandboxes while they don't mind nearly that every browser extension has full read/write access to everything people see and do.
EV has flaws, but it's better than literally anything else. We shouldn't be promoting HTTPS if it isn't solving this, the other problems it attempts to solve are mostly overstated problems. Because phishing is a vastly bigger threat than MITM.
EV has theoretical flaws but solves real problems, HTTPS without it has real problems and largely solves theoretical flaws.
Assuming there hasn't been, I think this just supports the idea that EV certs aren't useful: the bad guys don't even feel the need to try to use them maliciously!
That's my point: Systems that don't scale are less profitable to attempt to abuse for malicious ends, because more time and effort has to be invested into any given effort, and ideally, there are actual humans involved in the process which catch discrepancies.
The other reason you may not see a lot of attempts to find exploits in EV (apart from Ian) is that most of the actors sites want to pretend to be aren't using EV either. If you want to fake yourself as Google, EV isn't going to help you since Google doesn't use it.
I would argue the claim "bad actors aren't trying to abuse it so it isn't effective" to be silly, as that claim would apply among all methods that bad actors can't meaningfully abuse.
And before someone suggests that users can't be taught this, there's precedent: We've been trying to teach users not to trust that "Secure" badge/lock icon they've gotten used to. The difference is, the secure icon never represented that they were communicating with someone trustworthy, but the EV designation would.
EDIT: Also, hi Ian! stripe.ian.sh makes you a minor celebrity, and I'm honored by your presence. ;)
> forcing people to use HTTPS to avoid scare tactic "Not Secure" warnings.
"Not Secure" is a literal description of the state of the connection. Its not secure. What should a browser say? I guess nothing because your site is so special that its users should be ok with having someone MITM the connection and inject who knows what into the page. Whether or not that is OK isn't your decision to make - its the right of your users to make that decision and saying "Not Secure" helps them. That you find that inconvenient for you is well ... inconvenient for _you_.
> HTTPS is far less helpful than something like EV that includes identity
The article makes a pretty compelling point that EV certs are worthless and do no better a job at providing security than regular certs.
When people insist EV have value, they almost always base it on some hand-wavy claims about preventing phishing. Cite to research (not to advertising claims from CAs) showing that significant numbers of users are aware of EV and use it as an indicator when deciding whether to trust a site, for example.
The problem is you won't be able to; the average web user is barely aware of what the various things in the URL bar mean, if they're even aware of the URL bar at all, as decades of user research have taught us. So it always just comes back to hand-wavy stuff. And hand-wavy isn't enough to justify the cost of the system.
Meanwhile, we have real, hard evidence that even technically-literate, security-savvy users can easily be fooled into giving up their credentials, and even will bypass mechanisms intended to get in the way of them giving up their credentials. I'm going to keep plugging this phishing talk until everyone has internalized that message:
We have an expert here, writing they are useless.
We have various case studies of different websites using them and then switching away from them without any user outcry - again, showing they are useless.
We have various examples of CAs making highly misleading claims with a clear intent to financially benefit themselves.
We have a "warranty" that no one will explain what it means.
We have major browsers, saying they are worthless by removing their special treatment.
We have major websites voting with their feet, never using them, indicating they are useless.
Its extremely unclear to me exactly what you are objecting to. Maybe if they were useful, then, they would be useful, but, that's circular.
What we're seeing now is the convergence of forces that are pushing short-lived, automatic DV certs and players who are keen on de-emphasizing EV's imperfect role as a destination surety signal.
Big sites can get by with DV because people trust big sites by fiat, just by mental associations they already have to a URL. There's no benefit to Facebook having an EV cert, because literally everyone who'd want to visit Facebook knows Facebook's URL. User error about entering credentials on the wrong site -- accidentally due to typosquatting, or through leading such as phishing -- is better mitigated in other ways: multi-factor authentication (especially unproxiable such as U2F); not by making the high-profile site pay thousands of dollars for a text string in green, when there's users who fall victim to phishing from bizarre domains too.
If a CA flogs a guarantee for very expensive certs, but fails to explain what it entails. Then bloviates about nerds on the twitter account of the CEO to then block Troy (who, once again, asked a super legitimate question) then they not only deserve all the snark slung into their general direction.
No, they deserve to fucking die!
I feel that EV certificates do have their use for high-worth targets (banks and so one). Getting one is not trivial and definitely not scalable. Maybe they are a bit overpriced, maybe the certificate industry is kind of sketchy, but that's other debates.
But a machine should be able to distinguish. There should be an Expect-EV pin header, just like HSTS and Expect-CT. That way you can be sure the certificate wasn't issued via DNS hijacking.
1. Can an arbitrary third party eavesdrop on my communications?
2. Am I communicating with who I think I'm communicating with?
It is now extremely easy to handle use case (1). Use case (2) is still genuinely hard, because even extremely technically literate security-savvy people can still easily be phished (my current go-to example is this talk: https://www.youtube.com/watch?v=ZjW12K0IHgo).
Compounding the problem, many people insisted, for many years, that use case (2) was the overwhelming majority of all the value of SSL/TLS, and use case (1) was at best a tiny microscopic fraction of a fraction of a fraction of what was useful about SSL/TLS.
Lest you think I'm exaggerating: I've spent years arguing with people, including right here on HN, about this, and being condescendingly told that identity verification is the crown jewel, and that if I'm not going to make use of that then I might as well literally just go back to plain unencrypted HTTPS, because apparently that's actually better than using SSL/TLS without identity verification.
Also, I really recommend watching that video I linked. It's a security engineer at Stripe, talking about how she ran some pretty successful campaigns within the company. Whatever you may think of them, they're not unlettered philistines. But even things like your "Expect-EV" wouldn't have helped -- she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway. There just aren't any easy "just do X" technical solutions here.
One big reason people do that is because probably 99+% of the time their password manager fails to fill the fields is not because it is the wrong site.
It is almost always because the site has done something with its fields that is either preventing the password manager from finding the fields, or is blocking it from filling them (often intentionally).
The issue is that credential stores which know how to recognize the "real" version of a site aren't going to achieve the level of effectiveness we'd like to have against phishing.
Encryption without identity verification is objectively worse than no encryption at all. The reasons are straightforward:
• Encryption isn't free. Whilst performance has improved, there's no heartbleed without OpenSSL. It adds complexity, it adds a TON of extra work and operational problems like key expiry policies, and in general increases your attack surface.
• We generally feel the complexity is worth it to block MITM attacks. But if you are just handshaking with whatever is answering your packets, you aren't blocking MITM attacks.
The assumption underlying your position is (being generous) that the world is full of passive MITMs who can't also take part in the conversation, so any Diffie-Hellman key exchange will knock them out. But Snowden proved conclusively that this isn't true. Local attackers can do ARP spoofing, packet injection and other tricks and remote attackers are the NSA who also can perform large scale packet injection and active MITM attacks. Where are the passive-only attackers?
If you aren't stopping active MITM, then there don't seem to be any adversaries you are actually stopping, and at that point the additional (potentially hackable) code required and additional work required is just nothing-for-something.
When I was in college I used to teach friends the importance of encryption by just showing them a live dump of packets on the dorm's LAN. You could see everything: here are the IMs coming to you and getting your away message as a reply, there's your computer refreshing the news site you were looking at a minute ago... it opened their eyes in a big way.
Encryption -- even without checking seventeen forms of government-issued ID from the person on the other end -- does in fact stop that passive surveillance, and like it or not that's a gigantic use case.
The realistic threat model for most people in terms of active MITM is something like their ISP trying to inject ads and tracking into what they browse, or their home router getting compromised. It takes very very little in terms of identity verification to shut that down; DV certs, which you can get by the truckload, for free, from Let's Encrypt -- will handle it just fine. Which means you don't need EV for that.
As to Snowden, I'm reminded of James Mickens' famous breakdown of threat models. All the Ultra-Verified Premium Secure XP+ Guaranteed™ certificates in the world ain't gonna help if a major government decides to come for you.
EV is snake oil. It literally does not solve any realistic problem the average person has when using the internet; all it does is line the pockets of the cert vendors. DV is the absolute most you need to shut down the things you can shut down, and encryption in general -- even without verification! -- is just fine, thanks. I know I might have a secure channel to Satan. I care about the "secure" part, not the "Satan" part.
Also, as I often do when faced with a true believer, I'll ask you: how many times have you initiated an SSH session with some host for the first time and just accepted past the initial warning? If encryption without rigorous verification is "objectively worse than no encryption at all", why didn't you just telnet instead?
Expect-EV would prevent attacks like where a domain is hijacked via DNS or BGP. U2F wouldn't help with these attacks. I know that phishing is a much bigger problem than domain hijacks, but domain hijacks do happen, so it would be nice to have protection.
And yes, machines can distinguish EV, there's an OID (field) if every EV cert for it.
EV doesn't have the user distinction benefit of a blue checkmark if no major websites use it. No one notices EV. Twitter randomly switches between EV and non-EV, but no one gets worried.
Any system starts from no usage, and no education and works up - every bank, payment and fintech company is a pretty good start. Browser security indicators resembling more common verification indicators would help.
Yeah, I agree EV has some potential for users to distinguish. If we add mechanical way for the browsers to enforce it, that could help increase website adoption, and thus also help users to notice it more.
a lot of B.S. there too
The whole experience left a stale impression: we were then in the process of switching to non-profit and already dissolved the for-profit company but got the EV for the old company anyway! Clearly the CAs have a moral hazard: if they check too thoroughly they will sell less certificates, so it is not in their interest. In my case they blatantly asked me to provide bullshit evidence for the dissolved company!
No wonder that Microsoft Smartscreen doesn't seem to treat EV certificates as all encompassing truth of existence of something. We had to jump through some more hoops to satisfy Smartscreen, the certificate alone was not enough.
However, now that EV certs are clearly going the way of the dodo, the risks associated with them are likely to increase. CAs are going to be exiting the EV business (and/or going out of business themselves). The dwindling market is also likely to increase the price of an EV cert, rather than decrease it, as remaining purchasers will have a specific need to use an EV cert.
It might be time to re-evaluate.
For now this has given me the impetus to ditch Chrome. All of the other major desktop browsers still provide useful UI for EV certs. I’m less inclined to deal with finances on mobile through a website anyway, as every financial org I’ve had to deal with has an app, and Apple ends up being the gatekeeper in that realm.
Hopefully there will be some sort of push for useful additions to certificate security coming out of Google, as right now they seem more determined to just be undermining things.
* The dis-trusting of basically every skeezy dis-trusted CA.
* The adoption of TLS 1.3.
* Certificate pinning.
* HSTS preloading.
* The modernization of OpenSSL.
* The Heartbleed attack that prompted the modernization of OpenSSL.
* Certificate transparency.
I'm rattling these off my head and certainly forgetting something. Obviously, if you broaden the question to everything relevant to browser security, the list gets much longer.
All the heavy lifting continues to be done by m.d.s.policy, which is Mozilla's, not Google's if it's anybody's. I used to want to believe that the (behind closed doors) other root programmes also had their own effective mechanisms. A few years of working with m.d.s.policy and watching absolutely nothing else making any difference disabused me of this notion. It gets done in public or it doesn't get done at all, and m.d.s.policy is where it gets done in public.
Does Google have (mostly in the form of Ryan Sleevi who is a Google employee) a contribution to m.d.s.policy? Sure they do. But there are quietly also people from Microsoft and others paying attention, it's just that Ryan is much noisier, for good or bad.
If I was going to single out a _person_ for this work it would be the late Gervase Markham, who was a Mozilla employee. The big list of problems at StartCom is Gerv's list, for example. I think even the idea to go after auditors not just CAs was Gerv's idea.
Personally, I've found their handling of the Symantec root distrust mediocre (from the perspective of an affected site owner). However, the biggest issue is the changes to the display of certificate info in Chrome 69. To present a certificate with an authenticate legal entity the same as an insecure site indicates we have different priorities, and they no longer align.
[icon] Grey Text | example.com
Secure, non-EV sites show up as:
I actually suspect you're mostly right (the EV color is green, not gray, in the Chromium I'm using, but I can imagine this not being easily visible under many conditions), but the way you've decided to talk about this has made me very hesitant to openly agree with you. But for those whose answers are meant as “it says ‘Not Secure’, therefore it's adequately different”, I might be skeptical on the grounds of “having the user know that requires clearing a higher attention bar first”, aka “users don't read”.
Yes, the decision seems to be intentionally making them confusing. That or else I can only assume they didn't really think through the design decision much.
However, my understanding is that Google is intending the EV company info to be removed from the address bar altogether in a future release. Both of these decisions seem to be poor choices, in my opinion, and I think it is a loss of useful information.
By contrast, Safari 12 no longer displays the EV company name in the address bar, however EV certs result in the lock and domain name being green, and if you click on it, you get a nice popup explaining what legal entity the certificate is issued to. In Chrome, to get that information you have to dig a few levels deep, expanding a tree control and understand X.509 certificate fields.
Based on that changes that are being made in Chrome, it seems they want it to be difficult to learn what information is contained within the cert. But then the rationale is that no one understands what EV certificates means. If there was an honest effort in helping users understand security, I would think their experiments would involve making it easier to find certificate details and understand them, not remove them and make them similar to non-secure sites. This is why I said in my original comment "Hopefully there will be some sort of push for useful additions to certificate security coming out of Google, as right now they seem more determined to just be undermining things."
It isn't too far a stretch to think that the lack of effort in improving he display of certificate information and trying to downplay URLs is because Google wants more users to become more dependent on them as the way to find and authenticate web sites.
Considering your point that the way EV are displayed is similar in form to not secure, I find it weird. As the article points out, on mobile the EV looks not different than a DV. On desktop, it is written the full EV name versus the "Not secure" label.
It seems EVs are on their way out, you should at least concede that. It seems the Chromium team are pushing for accentuating the top domain name instead, so there's that.
I think you're approaching this precisely backwards.
> All of the other major desktop browsers still provide useful UI for EV certs.
There is no useful UI for EV certs, because EV certs are not useful.
> right now they seem more determined to just be undermining things.
Based on what criteria? It seems that Google and my interests are aligning less and less. I am starting to care more about privacy. And now Google is removing useful features that I use regularly, so I am stopping using one of their main products, and starting to look into alternatives for other product.s
> There is no useful UI for EV certs, because EV certs are not useful.
You are incorrect in this statement. They are useful to me, because they help me ensure that I am interacting with the website belonging to the company I have an existing relationship with.
> Citation needed?
The citation was the topic of my post. In Chrome 69 they are making the UI for EV certs confusingly similar to non secure sites. The handling of the removal of the Symantec root was handled poorly in terms of helping site operators know they could get a replacement certificate from DigiCert. As a certificate consumer, these are the two interactions I've had with Google in regards to certificates, and both have been negative.
The article makes pretty compelling points that almost no one finds EV certs useful. Maybe you do. Maybe you think you do. I dunno. But, regardless, unless the article is wrong, you are in a tiny minority. Removing special handling of EV certificates reduces pressure on people to buy these certs based on false promises being made about them being generally useful - and that's a good thing.
> The handling of the removal of the Symantec root was handled poorly in terms of helping site operators know they could get a replacement certificate from DigiCert.
The problem with Symantec having horrific security was that Google handled it wrong? This was Symantec's issue. I also don't like that when I google "Do I have to pay my parking tickets" the answer is yes - but that isn't Google's fault either.
2. I asked __apf__, who is in charge of browser security UI in the Chrome team, and she told me they've done no research.
Google and I are starting to align less and less. Removing a useful feature that helps me maintain security gave me the push to try other options. I don't care how small you may consider the change, if it increases the chance that I fall pray to a phishing site, I'll use another tool that does help me.
I'm not really sure how that is any difference than what I said. Google has made a minor UI change that the article makes a pretty compelling case is in the user's best interest. You are making a public declaration with an unclear audience that you won't stand for it.
> Removing a useful feature that helps me maintain security gave me the push to try other options.
The single biggest thing you can do to ensure your security is to use a password manager that auto-fills your passwords. Password managers can't be fooled by look-alike URLs. You can switch to another browser (and yeah, avoiding a browser mono-culture is a great thing!). However, I suspect strongly that you're going to see the other vendors follow suit and drop the special designation for EV certs. And good riddance. The article makes a pretty compelling point that CA certs aren't useful.
That link is about Show HNs - and this isn't a Show HN.
What really grinds my gears are companies selling nonsense that is actively hurtful. And the article makes a pretty compelling point that EV certs are pointless - and they cost a whole bunch of money - and that makes them actively hurtful. And, then we have a self aggrandizing comment here with no clear audience defending a status quo that helps no one and hurts small businesses. That, I find disrespectful.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.