(apologies to anyone who gets this twice, my first email got sent to some
spam folders, so I took out the example domain I used)

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 a similar
phishing domain 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

Reply via email to