Ensuring Web PKI Integrity
Meetup
Summary Report
04-Nov-2017
The Ensuring Web PKI Integrity (EWPI) meetup[1] assembled 39 participants, from industry and academia, for a day to discuss how to better protect users in the face of increased use of trusted TLS endpoints to engage in phishing and malware distribution. The participants included representatives from certificate authorities, domain registries, internet security firms, brand protection firms, browser vendors, and financial technology. The discussions covered the problem space, threats, constraints, and mitigation opportunities. The meetup ended with some high-level recommendations that it is believed would help more fully protect users if implemented, as well as some concerns that need to be taken into account in order to help the Internet remain openly available. This is the summary report of the meetup[2].
Summary
The Web is moving from being default-insecure, to being default-secure[3] [4][5]. By default-insecure, we are referring to the earlier situation where most websites (among the top 100-trafficked ones, say) were mostly only available over insecure HTTP, and web browsers defaulted to always attempting to establish an insecure HTTP connection unless instructed otherwise by a user. By default-secure, we are referring to the situation emerging today where, among the Google Transparency Report Top 100 websites, greater than 50% are now available only over HTTPS [7], and web browsers default to using secure HTTPS for websites deploying an HSTS Policy [10]. Indeed, as illustrated in table 2 of [5], by Feb-2017 10% of the Alexa Million websites were default-secure, up from 5% less than a year earlier.
This migration to being default-secure is enabled and driven by several factors, including:
Not terribly surprisingly, as these factors are enabling/driving the Web to be default-secure, cybercriminals are utilizing these enablers and also migrating: we are experiencing increased use of trusted TLS endpoints to engage in phishing and malware distribution [9][12][15][18].
By trusted TLS endpoints we mean HTTPS servers presenting a valid, legitimate certificate issued by a Certification Authority (CA) represented in consumer web browsers’ factory-installed trust store. Unfortunately, this is arguably resulting in diluting the effectiveness of browser security indicators [18]. Additionally, addressing this particular aspect of the overall problem space of user safety on the Internet is not the sole responsibility of CAs [1].
Given these motivations, this meetup was organized in order to consider the question:
How do we protect consumers as we transition to a default-secure Web?[4]
Discussion
The participants characterized the high-level categories of threats to consumers as:
In discussing the overall problem space in the context of the above threats, these two key themes/concepts emerged[5]: trustworthiness and reputation.
In this context, trustworthiness is an individual’s -- i.e., a user’s -- assessment of whether a website is “safe” to interact with or not. While reputation is another’s -- i.e., the community’s or an authority’s -- assessment regarding the website. Participants noted that there is a tussle between between user-assessed trustworthiness and reputation as determined by Authority Blacklist Services (ABSs) (e.g., Google Safe Browsing and Microsoft Windows Defender SmartScreen). In the former case, simply verifying that a site’s certificate is valid does not indicate whether or not the site’s content is safe or malicious. In the latter case, it was noted that reputation systems are only as accurate as their input data, and also may be biased.
Recommendations
Upon discussing a broad range of underlying problem space facets and potential mitigations, the participants developed a rough summary consensus that:
Openness Concerns
Additionally, there was an expression of concern over the possible, or further, erosion of Internet openness. For example:
Proposed Follow-up Actions
Form appropriate formal or informal working groups (leveraging relevant standards development organization(s) (SDOs) as appropriate) to:
References
[1] Josh Åas. “The CA's Role in Fighting Phishing and Malware.” (29 Oct 2015)
[2] Bahajji, Z. A., Illyes, G. “HTTPS as a ranking signal.” (Aug 2014)
[3] Chromium Security. “Marking HTTP As Non-Secure.” (not dated)
[4] Paul Ducklin (Sophos.com). "Halfway there! Firefox users now visit over 50% of pages via HTTPS." (18 Oct 2016).
[5] Felt, Adrienne Porter, Richard Barnes, April King, Chris Palmer, Chris Bentzel, Parisa Tabriz. "Measuring HTTPS Adoption on the Web." (Aug 2017).
[6] Felt AP, Reeder RW, Ainslie A, Harris H, Walker M, Thompson C, Acer ME, Morant E, Consolvo S. “Rethinking Connection Security Indicators.” (Jun 2016)
[7] Google Transparency Report. “HTTPS encryption on the web: On top sites.” (on-going, viewed 4 Nov 2017)
[8] Google. “Certificate Transparency.” (on-going)
[9] Derek Gooley (Zscaler blog). “The Rise in SSL-based Threats.” (16 Feb 2017)
[10] Jeff Hodges, Collin Jackson, Adam Barth. “HTTP Strict Transport Security (HSTS).” (Nov 2012)
[11] Jeff Hodges, Hubert Le Van Gong, Josh Åas. “Ensuring Web PKI Meetup (EWPI): Setting the Context.” (13 Sep 2017)
[12] SC Media. “SSL encrypted malware doubles this year, phishing over SSL/TLS up 400%.” (03 Aug 2017)
[13] Schneier on Security. “Let's Encrypt Is Making Web Encryption Easier.” (14 Dec 2016)
[14] Mozilla Security Blog. “Moving towards a more secure web.” (20 Jan 2017)
[15] Paul Mutton. “Phishing sites react promptly to new browser changes.” (17 May 2017)
[16] Qualys SSL Labs. “SSL Server Test.” (on-going, viewed 23 Sep 2017)
[17] Squarespace. “Squarespace and SSL.” (October 5, 2017)
[18] Jake Swearingen (NYMag.com). “Just How Safe Does That HTTPS Green Padlock Keep You?” (07 Mar 2017)
[19] US Government CIO Council. “The HTTPS-Only Standard.” (Jun 2015)
[20] Wordpress.com. “HTTPS and SSL.” (not dated)
[1] Held at PayPal offices in San Jose, California, on Wed 13-Sep-2017
[2] The full meetup notes are available here.
[3] Where "secure", for our purposes here, means at least a domain-validated certified binding of the server’s domain name and its public key, thus enabling authentication that the contacted server wields the associated private key, and that there is connection confidentiality and integrity protection. This definition assumes the DNS is not compromised.
[4] Original formulation: Given the realities of today's Web PKI, the DNS system, and their underlying infrastructures and policies, how might we work together to reduce the time-to-assess, and to increase user awareness of, website content intent and safety in the face of increased use of trusted TLS endpoints to engage in phishing and malware distribution? [11]
[5] It was noted that while threat categories may never be complete -- i.e., new threats constantly emerge -- an enumeration of presently-understood threats can act as a useful mechanism for scoping the discussion.