Hi Paul, Those statements are both hyperbolic representations of others' points of view.
There are plenty of people who are skeptical about the effectiveness of EV and its associated UI who nonetheless believe that some sense of trustworthiness about websites is important. For example, Mozilla integrates the Safe Browsing system into its applications to protect users from malicious websites, regardless of whether the connection to that website was secure. There are also plenty of people who don't enjoy the sight of certificates imitating PayPal domains being issued by Let's Encrypt, and may think that this is a symptom of a larger problem - but still don't agree that intervention by the CA is the appropriate tool to handle that problem, for reasons such as the lack of a formal process for adjucating claims (like the UDPR for registrars), or a general concern about censorship, or an observation that malware and phishing sites are often deployed to specific pages on otherwise-good services and that hostname-level enforcement is a mismatch for the problem. Putting the hyperbole aside, the general sentiment behind both of those statements is consistent, and not something I think is in urgent need of clarification by Mozilla. Further, there are ongoing efforts to improve online security and trustworthiness that don't rely on CAs doing anything at all. Services like Microsoft SmartScreen and Google Safe Browsing are one of those. The deployment of phishing-resistant WebAuthn-based authentication is another. Not speaking for anyone else here, I personally see it as futile to rely on user education for nearly any aspect of security. Instead, we should be designing systems that do the right thing on the user's behalf wherever possible. This doesn't necessarily have to rely on large benevolent central services: WebAuthn is an excellent example of a standard that can be implemented by anyone in software or hardware, without getting any company's permission, and integrated in the way that makes the most sense for users of that service or platform. WebAuthn relies on the domain name to resist phishing, but doesn't rely on the user having to watch to make sure they are at the right domain name. If someone ends up at g00gle.com and doesn't notice, the WebAuthn-based authenticator (whether a YubiKey, a smartphone fingerprint reader, or a Macbook Touchbar, etc.) will notice on the user's behalf that the domain name differs from the website that the authenticator was originally registered at. That's a very smart model that renders many common classes of attacks infeasible for even highly well-resourced attackers, while requiring no user education about how websites or certificates work. And as people get used to using authenticators that are built into their phone or laptop, and use the same ceremony that people use to log into those devices themselves to also log into websites, there will be no user education required for how to benefit from these advancements. I'm not trying to argue that WebAuthn alone will save the web, but rather pointing to it as a fruitful example of where resources are being poured *instead* of user education or on greater reliance on CAs for ecosystem monitoring. No one's just sitting back and not caring about phishing: instead, the ecosystem is responding to the threats as they've observed them, using a model that is already showing real results in the real world with real users. On Tue, Oct 8, 2019 at 2:04 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > On Oct 8, 2019, at 4:19 AM, carsten.mueller.gl--- via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > > >> But the target audience for phishing are uninformed people. People > which have no idea what a EV cert is. People who don't even blink if the > English on the phishing page is worse than a 5-year old could produce. > >> > >> You cannot base the decision if a EV indication in the browser is > useful on those people. > >> > > The discussions that many users don't even recognize the difference > between EV/OV/DV certificates is unfortunately true, BUT forced by the > browsers: > > > > When EV certificates were introduced, each browser displayed a green > address bar including the company name and the country abbreviation of the > certificate applicant. > > Gradually the green colouring of the address bar was removed and only > the company name and country abbreviation were displayed in green. > > To top it all off, the lock symbol of ALL certificates was displayed in > green to make the confusion of the users perfect. > > Google Chrome also removed the green color of the company name. > > > > Each browser then had a different display of all certificate types at > short intervals. > > > > > > In the early days of EV certificates, it was easy for me to tell my > mother and " uninformed" friends that they should pay attention to the > green address bar and the company name displayed there, and if possible not > make any purchases or data inputs at all on other sites. > > > > It was so simple: green address bar + some intelligence > 99% security > > > > Today: > > - no normal user can display the contents of certificates > > - no normal user can recognize which certificate types are actually > involved > > > > > > Of course, you can never be 100% sure that when calling a website with > an EV certificate: > > - no one has stolen the certificate > > - another company with a similar name operates a phishing site > > However, the effort to do this is so much higher that it is hardly worth > it, see below. > > > > > > Also it is pointed out here again and again that EV certificates are so > insecure, because e.g. a certificate for https://stripe.ian.sh was issued > for Stripe, Inc located in Kentucky and was displayed by the browsers > exactly like the EV certificate from Stripe, Inc. > > This is not a reason for abolishing EV certificates, but rather a reason > to talk about the UI of the known browsers. > > Each EV certificate lists both the location of the company and the > registry. Therefore, you can also display "Fima/State/Country" in the > address bar of the browser. > > > > In addition, it is still much more complicated to operate a fake website > with an EV certificate (I come from Germany, therefore related to Germany): > > - Foundation of a corporation (GmbH): > > o min 15.000,- EUR > > o Appearance of at least one person at a notary and verification of all > data > > o Verification of all data by commercial register > > - Application for EV certificate > > > > I would like to link to a study on the use of EV certificates for > phishing: > > > https://sectigo.com/uploads/resources/Understanding-the-Role-of-Extended-Validation-Certificates-in-Internet-Abuse.pdf > > > > If the formation of a corporation in other countries is > faster/simpler/cheaper, it still does not contribute to abuse. > > > > > > My opinion: > > EV certificates are not 100% secure, BUT they increase security > enormously. > > > > > > Why do browsers want to make the Internet less secure? Instead of > abolishing the EV indicators, they should rather be fully activated again, > including the green address bar. > > > > Carsten > > [PW] Very well said Carsten. I’d like to add something that bugs more more > than anything else - it’s hypocrisy. > > “Read this blog post - it proves that it’s possible to trick the system to > get an EV Certificate. It doesn’t matter if it has never happened. EV is > broken. Let’s get rid of all website identity.” > > AND > > “It doesn’t matter if Let’s Encrypt has issued 14,000+ DV certs to domains > with PayPal - we believe every website needs to be encrypted. And Let’s > Encrypt isn’t responsible for phishing." > > Can Mozilla please reconcile these two assertions? I still can’t get my > head around it. > > - Paul > > > > > > > > Translated with www.DeepL.com/Translator > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
