16 ms·

Extended Validation Certificates Are Really Dead

162 points by dyates 7y ago

Ajedi32 7y ago
Direct link to explainer doc in the Chromium source: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... (Permalink version https://chromium.googlesource.com/chromium/src/+/bccea73462da42b6366dd4d8dc391ee07c615312/docs/security/ev-to-page-info.md https://chromium.googlesource.com/chromium/src/+/bccea73462d...) Chrome mailing list announcement: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI https://groups.google.com/a/chromium.org/forum/#!topic/secur... Firefox mailing list announcement: https://groups.google.com/forum/#!topic/firefox-dev/6wAg_PpnlY4 https://groups.google.com/forum/#!topic/firefox-dev/6wAg_Ppn... Firefox bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1572936 https://bugzilla.mozilla.org/show_bug.cgi?id=1572936
SAI_Peregrinus 7y ago
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.
vbezhenar 7y ago
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.
- jamesponddotco 7y ago
  Still need others for things like S/MIME, which are not supported by Let's Encrypt.
  - hannob 7y ago
    Appart from the fact that S/MIME is inherently broken: That would be no reason to keep them in browsers.
- Ajedi32 7y ago
  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.
  - vbezhenar 7y ago
    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.
    - eridius 7y ago
      > 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.
  - M2Ys4U 7y ago
    Yes, and we need ones that aren't in the USA's jurisdiction, too.
cevn 7y ago
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.
- Someone1234 7y ago
  Not all Code Signing certificates are Extended Validation. Non-EV Code Signing certificates bypass that warning (Authenticode). So it has no impact. Code Signing will still be $175 too expensive and still work just as they have.
  - donmcronald 7y ago
    Non-EV requires SmartScreen trust building though, right? Register a company, buy an EV cert, sign your malware. The only barrier is $ because there’s no limit on creating cheap companies. The whole “trust” industry is ripe for disruption if someone can get Microsoft on board.
  - zanderz 7y ago
    MS still requires that drivers be signed with an EV cert https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate 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.
    - judge2020 7y ago
      New EV certificates don't just help with SmartScreen, they completely bypass it. Regular Windows code signing is the smartscreen booster.
- gruez 7y ago
  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. [1] https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-smartscreen-extended-validation-ev-code-signing-certificates/ https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-sma...
ocdtrekkie 7y ago
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. [2]Basically Google said it wants to "invent" EV certs here, late last year: https://www.wired.com/story/google-wants-to-kill-the-url/ https://www.wired.com/story/google-wants-to-kill-the-url/
- chimeracoder 7y ago
  > [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]. [0] https://stripe.ian.sh/ https://stripe.ian.sh/ [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.
  - wahern 7y ago
    > 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).
stefan_ 7y ago
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.
- Znafon 7y ago
  Why push for extended validation of there is no security benefits and the user experience is the same? I remember that someone had successfully got an extended certificate for "Stripe, Inc". Things like certificate transparency log monitoring seems better than EV to improve security.
  - stefan_ 7y ago
    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.
    - hsk823 7y ago
      Yes but none of those issues are fixed via extended validation of TLS certs. Extended validation was simply a cash grab and a human component to validating you are who you are beyond a domain name mismatch. EV process was the same as any other cert process, what ever company out there issues the EV was just doing extra leg work and making sure business registration paperwork was legit, etc. etc. It didn't make it more safe, it just added extra steps to validate ownership of a domain. MITM TLS proxies and shady root CAs are and will continue to exist in the enterprise and for state actors for the foreseeable future. EV does not challenge this, in fact EV certs like any cert that's intercepted properly, the end user will never know that it happened.
Ajedi32 7y ago
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.
- robocat 7y ago
  It would require an international register. You can surely get "Stripe Inc" in another country i.e. it isn't just an issue that can be solved at a federal level. Neither are trademarks useful because they are: per nation, per class (of goods or services), and are not pure text (icon matters).
  - Ajedi32 7y ago
    In theory, there's no reason why an icon couldn't be signed and displayed alongside the pure text label.
    - rocqua 7y ago
      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.
  - nailer 7y ago
herpderperator 7y ago
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:// https:// from the URL and EV being gone, I don't even know what to trust anymore.
- dbalan 7y ago
  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/ https://stripe.ian.sh/
  - herpderperator 7y ago
    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?
    - calebegg 7y ago
      Comodo said the revocation was a mistake: https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-an-ssl-certificate-for-kentucky-based-stripe-inc https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-...
nailer 7y ago
As someone with a direct interest in this (I run https://certsimple.com 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.
- Scott_Helme_ 7y ago
  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.
  - nailer 7y ago
    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.
bronzeage 7y ago
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.
- rocqua 7y ago
  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. [1] https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/ https://www.troyhunt.com/paypals-beautiful-demonstration-of-... edit: Claimed that EV differed based on location, but it was based on browser.
- eridius 7y ago
  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.
tgsovlerkhgsel 7y ago
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.
jillesvangurp 7y ago
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.

162 points by dyates 7y ago

Direct link to explainer doc in the Chromium source: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... (Permalink version https://chromium.googlesource.com/chromium/src/+/bccea73462da42b6366dd4d8dc391ee07c615312/docs/security/ev-to-page-info.md https://chromium.googlesource.com/chromium/src/+/bccea73462d...) Chrome mailing list announcement: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI https://groups.google.com/a/chromium.org/forum/#!topic/secur... Firefox mailing list announcement: https://groups.google.com/forum/#!topic/firefox-dev/6wAg_PpnlY4 https://groups.google.com/forum/#!topic/firefox-dev/6wAg_Ppn... Firefox bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1572936 https://bugzilla.mozilla.org/show_bug.cgi?id=1572936

SAI_Peregrinus 7y ago

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.

vbezhenar 7y ago

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.

jamesponddotco 7y ago
Still need others for things like S/MIME, which are not supported by Let's Encrypt.
- hannob 7y ago
  Appart from the fact that S/MIME is inherently broken: That would be no reason to keep them in browsers.
Ajedi32 7y ago
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.
- vbezhenar 7y ago
  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.
  - eridius 7y ago
    > 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.
- M2Ys4U 7y ago
  Yes, and we need ones that aren't in the USA's jurisdiction, too.

cevn 7y ago

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.

Someone1234 7y ago
Not all Code Signing certificates are Extended Validation. Non-EV Code Signing certificates bypass that warning (Authenticode). So it has no impact. Code Signing will still be $175 too expensive and still work just as they have.
- donmcronald 7y ago
  Non-EV requires SmartScreen trust building though, right? Register a company, buy an EV cert, sign your malware. The only barrier is $ because there’s no limit on creating cheap companies. The whole “trust” industry is ripe for disruption if someone can get Microsoft on board.
- zanderz 7y ago
  MS still requires that drivers be signed with an EV cert https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate 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.
  - judge2020 7y ago
    New EV certificates don't just help with SmartScreen, they completely bypass it. Regular Windows code signing is the smartscreen booster.
gruez 7y ago
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. [1] https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-smartscreen-extended-validation-ev-code-signing-certificates/ https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-sma...

ocdtrekkie 7y ago

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. [2]Basically Google said it wants to "invent" EV certs here, late last year: https://www.wired.com/story/google-wants-to-kill-the-url/ https://www.wired.com/story/google-wants-to-kill-the-url/

chimeracoder 7y ago
> [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]. [0] https://stripe.ian.sh/ https://stripe.ian.sh/ [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.
- wahern 7y ago
  > 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).

stefan_ 7y ago

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.

Znafon 7y ago
Why push for extended validation of there is no security benefits and the user experience is the same? I remember that someone had successfully got an extended certificate for "Stripe, Inc". Things like certificate transparency log monitoring seems better than EV to improve security.
- stefan_ 7y ago
  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.
  - hsk823 7y ago
    Yes but none of those issues are fixed via extended validation of TLS certs. Extended validation was simply a cash grab and a human component to validating you are who you are beyond a domain name mismatch. EV process was the same as any other cert process, what ever company out there issues the EV was just doing extra leg work and making sure business registration paperwork was legit, etc. etc. It didn't make it more safe, it just added extra steps to validate ownership of a domain. MITM TLS proxies and shady root CAs are and will continue to exist in the enterprise and for state actors for the foreseeable future. EV does not challenge this, in fact EV certs like any cert that's intercepted properly, the end user will never know that it happened.

Ajedi32 7y ago

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.

robocat 7y ago
It would require an international register. You can surely get "Stripe Inc" in another country i.e. it isn't just an issue that can be solved at a federal level. Neither are trademarks useful because they are: per nation, per class (of goods or services), and are not pure text (icon matters).
- Ajedi32 7y ago
  In theory, there's no reason why an icon couldn't be signed and displayed alongside the pure text label.
  - rocqua 7y ago
    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.
- nailer 7y ago

herpderperator 7y ago

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:// https:// from the URL and EV being gone, I don't even know what to trust anymore.

dbalan 7y ago
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/ https://stripe.ian.sh/
- herpderperator 7y ago
  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?
  - calebegg 7y ago
    Comodo said the revocation was a mistake: https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-an-ssl-certificate-for-kentucky-based-stripe-inc https://sectigo.com/blog/on-comodo-cas-recent-revocation-of-...

nailer 7y ago

As someone with a direct interest in this (I run https://certsimple.com 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.

Scott_Helme_ 7y ago
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.
- nailer 7y ago
  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.

bronzeage 7y ago

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.

rocqua 7y ago
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. [1] https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/ https://www.troyhunt.com/paypals-beautiful-demonstration-of-... edit: Claimed that EV differed based on location, but it was based on browser.
eridius 7y ago
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.

tgsovlerkhgsel 7y ago

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.

jillesvangurp 7y ago

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.