> On Oct 9, 2019, at 2:04 PM, Eric Mill <e...@konklone.com> wrote: > > (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.
[PW] This is unhelpful Eric. I have referenced an enormous amount of data points across multiple messages - perhaps you could be specific about which of my “representations" you think are “hyperbolic” when replying to my previous messages? And if you don’t mind, provide some evidence-based metrics to demonstrate why you think they are hyperbolic. There is a lot of hyperbole in this debate so I appreciate you calling me out - but it would help if you were specific - but you need to go through my previous posts. > > 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. [PW] “people who are skeptical” is an opinion about other people’s opinions. I question the effectiveness of EV too - because the UI/UX designers at Mozilla didn't implement good visual indicators for website identity. I’m glad we agree on this. I’ve already provided data driven evidence and techniques to help demonstrate why Google’s Safe Browser API is not addressing the problem. Perhaps you can revert back. > > 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. [PW] I don’t disagree with anything you said above. Just to clarify, I never said CAs could or should intervene with Let’s Encrypt. If you revert back to my scribbles you’ll find that I provided data and insights to explain why criminals favor free SSL certs from Let’s Encrypt. I believe an alternative icon to the encryption lock would make a massive difference to combating the security threats that involve dangerous links and websites. I provided data to back up my beliefs. > > 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. [PW] You’ve brought up hyperbole again - I think you might have missed some messages from me - I’ve provided so much data it’s coming out of my ears. But fear not, I have been asked to write a guest post that will be published by the end of this week - it will have absolutely everything I’ve ever said, in a single essay. I’ll post a link when it’s published. People can then pick it apart if they have the time, energy and interest. Now, you refer to “general sentiment” - can we stop this? I don’t call that hyperbole but it pretty much amounts to the same thing if measured in added utility. We need less of this and more data. Everyone has an opinion. Everyone has the right to an opinion. But we should take opinions more seriously when coupled with data. Criminals have used Office365 to phish Microsoft employees while using Office365 and while being protected by Microsoft’s own massive threat intelligence system. The criminals then accessed all of Microsoft’s non-paying customers’ emails so they could gain access to their cryptocurrency. The reverse-proxy phishing technique bypasses Google’s own Safe Browser API inside their own WebView while their own users sign into Google pages while using Google’s Authenticator for 2FA. So their answer? In June 2019 they banned users from signing into Google’s pages while using mobile apps with a WebView. This tells you what you need to know about Safe Browser API - finally I have the evidence to prove that it’s an “ok” solution at best. Most security companies still think it’s great - because they’re not in possession of all the facts. WebAuthn-based security is something we can agree on being brilliant. Finally. However, we will not see mainstream adoption for it ever, or for a very long time. So, we need to do something to protect people for the next 5 years. Expecting it to help now is like inventing a new house alarm that most people either don’t know about, can’t afford, or see as unnecessary or too complicated. But again, it is a brilliant solution. > > 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: I agree. Did you read my findings in relation to website identity visual indicators being used by 85k active power users - with zero victims of a malicious link or website over an 18 month timespan? If not, I provided a huge amount of data around this. If you did read it and you still hold your opinion above, perhaps you can tell me where I’m wrong by referencing the data and techniques put forward. Without doing that, we can’t forward this debate in a meaningful way. > 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. I don’t disagree with any of this. But look at my comment about adoption. > > 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. To summarize, we agree that WebAuthn is brilliant. And on everything else, you fail to provide any insights or data to suggest why anything I’ve said is hyperbolic. There are many threads in which I have provided data, so it’s best to reply to those rather than a message that contains nothing but opinions - from you to me and from me back to you - no data - no evidence to back up anything. - Paul > > > On Tue, Oct 8, 2019 at 2:04 PM Paul Walsh via dev-security-policy > <dev-security-policy@lists.mozilla.org > <mailto: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 > > <mailto: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 > > <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 > > > > <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 <http://www.deepl.com/Translator> > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > > <https://lists.mozilla.org/listinfo/dev-security-policy> > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > <https://lists.mozilla.org/listinfo/dev-security-policy> > > > -- > Eric Mill > 617-314-0966 | konklone.com <https://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
