[Servercert-wg] Displaying secure sites to Internet users

Paul Walsh paul at metacert.com
Fri Nov 15 15:30:18 MST 2019

> On Nov 15, 2019, at 12:40 PM, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> wrote:
> On Fri, Nov 15, 2019 at 3:09 PM Christian Heutger <ch at psw.net <mailto:ch at psw.net>> wrote:
> Hi,
> This is an interesting essay, about a wide variety of topics unrelated to certificates and the CA/Browser Forum, but it's unclear what you believe the "problem statement" to be. I'm hopin you might be able to refine it further?
> SSL/TLS certificates have been introduced from my point of view for encryption and authentification (two security factors based on information security definition, refer to ISO 27001).
> While I'm quite familiar with ISO 27001, I don't think this dichotomy exists like you suggest. SSL/TLS already provide robust authentication of a domain name, which is how SSL/TLS is used on the Internet, and what the CA/Browser Forum concerns itself with. This robust authentication, when done following the Baseline Requirements and browser root programs, helps ensure users can reliably connect to secure sites on the Internet.

[PW] Please try not to use the word “authentication” in the context of anything related to DV. Consumers are the most important stakeholder. Here’s what “authentication” means to them:
to establish as genuine.
to establish the authorship or origin of conclusively or unquestionably, chiefly by the techniques of scholarship:
to authenticate a painting.
to make authoritative or valid.
Current browser UI and DV are not just used for good and bad like all technologies, they’re actively encouraging fraud and phishing attacks according to all the data points.

As a result of 911 it’s no longer legal to sell police uniforms in NYC. Law enforcement agencies recognized possible security weaknesses and decided to address them even if they were never exploited in the past. In the context of internet security, browser vendors are doing the complete opposite - ignoring all the data and all the problems. 

I separated fraud out from phishing because according to the Global Brand Counterfeiting Report 2018 [1] Brands lost $30.3 billion due to online counterfeiting in 2017.

I’ve published figures that show bigger numbers, and Webroot has done the same, but according to the APWG’s Q3 report published this week [2] [3]:

"More than two-thirds of all phishing sites used SSL protection. This was the highest percentage since tracking began in early 2015, and is a clear indicator that users can’t rely on SSL alone to understand whether a site is safe or not.”

"This year has been a clear turning point for threat actors adopting SSL certifications or abusing HTTPS as part of their phishing efforts. In June we observed for the first time that more than half of all phishing sites were using HTTPS. Now, in reviewing Q3, the number has spiked to more than two-thirds of all phishing sites or 68% after seeing a slight decline in Q2.”


Nothing to see here folks - if we listen to some browser vendors and some HTTPS “EVERYWHERE" advocates.

OR, if we could listen to brands and cybersecurity experts with direct experience with these problems.

> So I'm not quite sure this is a problem statement, since we've clearly "solved" this.
> In any event, hopefully that will encourage you to actually define the problem to solve, which you can then discuss how your preferred solution helps.
> Problem: Bring authentification (information security goal of authenticity) (back) to SSL/TLS ecosystem for deanomyzing the internet on users behalf not to fell victim of phishing, scaming and cybercrime. An additional factor is authentification therefor and a valid measurement are certificates issued by reliable third parties.
> I must admit, I'm still not sure I understand. I can understand that, due to CAs' presentations not being available yet, it may not be clear what started this discussion.
> However, it seems like the suggestion is "People fall victim to phishing, and we should try to solve that", and the proposed solution is "The Internet should not be anonymous". While your problem statement may be uncontroversial, that doesn't mean the CA/Browser Forum is a good venue for that, nor is the proposed solution necessarily desirable. However, it's certainly something you could pose.

[PW] The purpose of this forum is to discuss these issues. The fact that you don’t understand why, is irrelevant. It’s happening. 

I don’t understand everything but I do appreciate when more experienced people than me, do understand. So I defer to their better judgement. I defer to your better judgement on most matters discussed in this forum. Perhaps you should do the same here.

I wish Luke Wroblewski had conducted research into browser UI for identity. If he had I’d read it a hundred times because the guy is a genius product designer with a personal reputation to maintain - I trust his intent.

> If the idea is that there should be a way to associate identity with domain names, that's not too unreasonable to explore. However, there's no need to do that with SSL/TLS certificates, which is the primary purpose of the CA/Browser Forum. Even if the idea was to do it in SSL/TLS certificates, we have the EV Guidelines to explore that. Unfortunately, we can see that the EV Guidelines don't really provide a consistent, reliable form of identity. When you look through https://wiki.mozilla.org/CA/Incident_Dashboard <https://wiki.mozilla.org/CA/Incident_Dashboard> , you can see rather remarkable incidents, from CAs responsible for the majority of EV certificates. Failures in businessCategory, failures in serialNumber, failures in locality and state names, jurisdiction data, the list goes on! What's interesting about this is that a number of these issues are the result of the EV Guidelines not placing sufficient normative restrictions, leading different CAs to reach different conclusions on the acceptability of certain practices.

[PW] You’re not adding any value here. You’re simply pointing to problems with no proposed solutions. I feel like we’re on loop.

> It seems like if folks want to advocate that CAs are well-placed to discuss identity in certificates, despite the rather damning evidence, then one of the first steps to do would be to ensure that data validated according to the EV Guidelines can be relied upon. That Incident Dashboard serves as a good starting point - ideally, we should have a ballot for the EV Guidelines for each of these issues. Unfortunately, I'm only aware of a single CA working to improve this as an industry - DigiCert - and even there, they've faced significant backlash from other CAs. That does seem unfortunate, and does seem like identity in certificates may be a failed experiment.

[PW] Dude, really? I don’t get it. Stop throwing mud - you represent an important brand. 

What about when Google was one of the companies that misused over 1 million certificates? Should I add this as an email signature? https://arstechnica.com/information-technology/2019/03/godaddy-apple-and-google-goof-results-in-1-million-misissued-certificates/ <https://arstechnica.com/information-technology/2019/03/godaddy-apple-and-google-goof-results-in-1-million-misissued-certificates/>

"A major operational error by Google has resulted in the issuance of at least 1 million browser-trusted digital certificates that don’t comply with binding industry mandates. The number of non-compliant certificates may be double that number, and other browser-trusted authorities are also likely to be affected.”

I omitted the other two companies mentioned because I’m not here to play a blame game.

I’m surprised that you are so confident when you represent what is arguably the world’s most creepy browser that’s being sued all over the world for selling personal data and lying about it.  Preaching to everyone here about privacy and security is not a good look - it’s toxic. Give it a rest or be prepared to have people tell you where your company is going wrong, ethically and technically. 

Back to work… validation of identity is important to get right. it’s important to improve. It’s vital to have browser trust before they display trust information to users. But this can be achieved with collaboration and the use of new technology and methodologies. And it can be discussed at the same time as browser UI.

> That said, we're fully supportive of any efforts that CAs would like to lead to systemically address these issues. It seems like we've got a number of opportunities here
> Enumerated list of all the recognized jurisdictions a CA may consult for incorporating details (DigiCert has provided such a list)
> Enumerated list of all the expected business identity information forms (that is, that appear in the serialNumber) for these jurisdictions. (DigiCert has suggested they will be proposing such a list)
> Enumerated list of the different forms of business entities (e.g. Non-Governmental Entities appear to be a challenge for a number of CAs)
> Enumerated list of all the locality information one can expect in a certificate
> After all, the goal of such EV Guidelines is to ensure a consistent and predictable result. For CAs who believe they're unaffected by the many industry issues, they certainly seem well-placed to contribute ballots to formalize best practices. And for the CAs that are affected by these issues, formalizing their remediations seems extremely useful.
> These efforts are nicely complementary to the efforts to improve audits and disclosures. After all, the failure to detect these issues by auditors should be of deep concern for the community, and looking to better capture auditor expectations and disclosures seem like a further effort to improve identity.
> All of these things seem well-within our chartered scope. Discussions of UI, of course, are completely outside the scope of our charter, and well outside the expertise of members of this Forum. After all, we've seen folks acknowledge that it requires product and UI expertise, and that's inherently per-product. Just as we wouldn't expect Windows and macOS to look identical, given how much their product experiences differ, it's completely unrealistic to discuss trying to normalize UI.

[PW] I agree that these are outside your expertise. But there are people here with more experience than anyone else in the world when it comes to these matters. 

I deleted stuff I really wanted to say, so I don’t just blurt out what I think. I do give pause and read what I write here. 

> Once we have reliable data in certificates, which we're clearly years away from having in the existing ecosystem, then it might be useful to figure out how to take advantage of that data in a way that helps users and reduces phishing. This is likely best accomplished by moving this data out of the SSL/TLS handshake, so that it better aligns with the Web security model, doesn't harm the security (encryption or authentication) of HTTPS, and helps explore how best to solve the problem(s) you seem to be concerned about. But that's a few years away, and requires us first solve the validation issues.

[PW] Given that Google is a CA and issues only DV certs, this could be perceived as anti-competitive. 

[1] https://us.fashionnetwork.com/news/Luxury-brands-lose-30-3-billion-due-to-online-counterfeiting-in-2017,977979.html <https://us.fashionnetwork.com/news/Luxury-brands-lose-30-3-billion-due-to-online-counterfeiting-in-2017,977979.html>
[2] https://docs.apwg.org/reports/apwg_trends_report_q3_2018.pdf (direct link to PDF download)
[3] https://info.phishlabs.com/blog/apwg-two-thirds-phishing-sites-ssl-https <https://info.phishlabs.com/blog/apwg-two-thirds-phishing-sites-ssl-https>

- Paul

> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191115/cc8f98c2/attachment-0001.html>

More information about the Servercert-wg mailing list