Browser Interfaces and EV-SSL Certificates: Confusion, Inconsistencies and HCI Challenges? Jennifer Sobey1, P.C. van Oorschot1, and Andrew S. Patrick2 1 School of Computer Science, Carleton University, Ottawa, Canada 2 Institute for Information Technology, National Research Council, Ottawa, Canada {jsobey,paulv}@scs.carleton.ca,[email protected] Abstract. The introduction of Extended Validation (EV) SSL certificates has caused web browser manufacturers to take a new look at how they design their interfaces for conveying certificate information. In turn, we take a thorough look at the choices they have made. Our observation is that the changes being made significantly increase the confusion surrounding SSL certificates rather than in- creasing trust. We perform a systematic walkthrough involving dialogues and in- terfaces related to site identity, certificates, and SSL encryption; raise questions concerning the inconsistencies in their implementations; and highlight the confu- sion between identity and confidentiality. Prior to carrying out a full user study, we aim to define the problem clearly and to explore some possible alternatives. We suggest some improvements in terms of both mental models and interface design and emphasize the importance of consistency across browsers for appropriate user interaction with these certificate interfaces. Key words: Usable security, extended validation, SSL certificates, browser secu- rity interfaces 1 Introduction In 1995, the traditional SSL certificate was first used as a way to provide encryption of private data being exchanged with a website and to provide some assurance as to that site's identity [30]. Now, fourteen years later, the loss of confidence in the standard SSL certificate has lead to the introduction of a new Extended Validation (EV) SSL certificate [12] that aims to restore that trust. Indeed, with growing use of the Internet for sensitive transactions such as online banking, it is increasingly important to provide a reliable way of distinguishing a legitimate bank web site from a fraudulent site. The addition of new EV-SSL certificates adds a layer of complexity to the already difficult design issue of conveying certificate information to the average user. The rather drastic modifications to the interface design of web browsers, which have not only added the new EV-SSL certificates but also changed browser handling of regular SSL and self- signed certificates, as highlighted herein, will in our view, significantly increase user confusion surrounding SSL certificates rather than improve on the current situation. While the present paper focuses on interface issues, other trustworthiness issues related ? Version: January 13, 2009. This note is a technical report on work-in-progress. 2 Sobey, van Oorschot, Patrick to SSL certificates have arisen in the past [18] and continue to appear, such as the recent flaw in a Comodo re-seller's process whereby they apparently had not done proper verification [23] and the ability to forge SSL certificates by finding collisions in MD5 hashing [19] which is surprisingly still in use. Even if these types of flaws relating to the certificates themselves ceased to appear, the interface problems discussed herein remain. In this paper we perform a systematic walkthrough involving dialogues and interfaces related to site identity, certificates, and SSL encryption. As a result we: (1) raise concerns about the current state of SSL certificate interfaces in web browsers (including IE, Firefox, Opera and Chrome), by highlighting the inconsistencies between browsers, changes made due to the introduction of EV-SSL certificates, and the failure to distinguish between site identity and confidentiality; (2) suggest possibilities for improvement, both in terms of users' mental models and in the actual design of the browser certificate interface; and (3) make a call to arms for unification and standards for SSL certificate interfaces in browsers. The remainder of this paper is structured as follows. Section 2 provides some back- ground on SSL certificates and usable security. Section 3 explores problems that lead to confusion with SSL certificate cues in web browser interfaces. Section 4 further explores the inconsistencies in current web browser interfaces. Section 5 considers improvements that could be made in these interfaces. Section 6 contains concluding remarks and open questions for future work. Appendix A contains figures illustrating the interface features for SSL certificates in the browsers being studied. 2 Background and Related Work 2.1 SSL Certificates and EV-SSL Certificates Secure Sockets Layer (SSL) [26] is a protocol commonly used in validating the identity of a website (certificates contain information about the certificate subject [26, 34]) and enabling the confidential transmission of information between browser and server over the Internet. It uses cryptographic keys to encrypt the data being transmitted and to provide a signature used in identification. In this paper, we are interested in SSL server certificates and unilateral authentication of the site; we do not explore client certificates or the mutual authentication capabilities of SSL. Traditionally, two cues implemented in web browsers have conveyed SSL certificate information: (1) the https indicator in front of the site's URL, and (2) the display of a lock icon somewhere in the browser chrome (the frame of the browser that includes menus, toolbars, scroll bars, and status bars). While the https indicator is simply an indication that encryption is being used, the lock icon provides additional information (when clicked) about the identity of the site providing that encryption. Extended Validation (EV) SSL certificates were established by the CA/Browser Fo- rum [3], a voluntary organization consisting of Certification Authorities (CAs) and Inter- net browser software vendors. They build on the existing technology of the SSL certificate but involve a more strictly defined issuance process. They originally had two primary purposes: (1) to provide users with greater confidence regarding the identity of the or- ganization that controls the site visited; and (2) to facilitate the exchange of encryption Browser Interfaces and EV-SSL Certificates 3 keys between the site and the user's web browser as done with traditional SSL server certificates. The prescribed EV-SSL issuance process is designed to ensure that the only parties which can obtain such a certificate are private organizations, government entities, or business entities having a physical location (business presence) in the real world and that are not listed on any government prohibited list or denial list. EV-SSL certificates have five required fields: organization name, domain name, jurisdiction of incorporation, registration number, and address of place of business. The need for this new type of certificate arose from the fact that some CAs were issuing standard SSL certificates without properly verifying certificate information and for fees as little as $30 (or even free 30-day trial certificates, attracting short-duration phishing sites), making it easier for attackers to obtain \legitimate" SSL certificates for fraudulent sites. 2.2 Users and Security Whitten and Tygar [32] discussed the unmotivated user property: security is a secondary goal for most users, who are primarily focused on tasks such as logging into a site or performing a banking transaction. Many users will miss subtle security indicators, and are not motivated to read manuals to learn their functionality. Conversely, security indicators that are too obtrusive risk that the user will ignore security altogether, either because they become annoyed or grow too accustomed to the indicator. Several studies have shown that the traditional cues used to provide certificate in- formation often go unnoticed [6, 7, 27, 31]. One study by Schechter et al. [27] involved removing the https indicator and having users login to a banking web site. All 63 partic- ipants proceeded to enter their password and complete the task, in the absence of this indicator. The lock icon is the security indicator most often noticed [7, 31] but its absence also often goes unnoticed [6], and even when used as a security cue by users, many do not fully understand its meaning [5{7]. The majority of users who do rely on this security indicator remain unaware of its identity feature [6, 7, 31] and do not reliably understand the concept of certificates at all [5, 6]. Jackson et al. [12] performed the first known evaluation of EV-SSL certificate support, on Internet Explorer 7.0. They explored picture-in-picture phishing attacks, in which attackers make use of images, within the content of a web page, that mimic a browser window. They found that the new security indicators had no significant effect on the users' ability to identify legitimate and fraudulent sites, and reported that no one in the untrained group even noticed the new features. In a more recent study involving the Firefox 3.0 Beta 1 interface for EV-SSL certificates, Sobey et al. [29] found that the subtle identity indicators in the browser chrome went completely unnoticed by participants, and even a modified indicator designed to be more prominent went unnoticed by half the participants. Of those who did notice the new indicator, a few participants conveyed some understanding of its intended use, but most apparently did not attempt to interpret its meaning. Both studies underline the challenge of introducing new security indicators into existing web browser interfaces in a manner that is obvious and intuitive for the average user. 4 Sobey, van Oorschot, Patrick 3 Problems With Interfaces for EV-SSL and Other Certificate Types 3.1 Failure to Identify the Target User When designing a user interface, such as for displaying or conveying SSL certificate in- formation, it is critical to consider the target user of the interface; this is a well known human-computer interaction (HCI) principle. It is unclear if developers of each of the browser manufacturers have thought through who the target users are for their new SSL certificate interfaces (any such target has yet to be communicated, to our knowledge), or whether those users have sufficient information or background to take appropriate actions.