Identification of Web Sites and Certification Authorities

Currently, browsers identify the provider of the web page by indicating the Universal Resource Locator(URL) of the web page in the location bar of the browser. This usually allows knowledgeable web users to identify the owner of the site, since the URL includes the domain name (which an authorized domain name registrar allocates to a specific organization; registrars are expected to deny potentially misleading domain names). However, the identity of the provider is not necessarily included (fully) in the URL, and the URL contains mostly irrelevant information such as protocol, file, and computer details. Furthermore, the URL is presented textually, which implies that the user must make a conscious decision to validate it. All this implies that this mechanism may allow a knowledgeable web user, when alert and on guard, to validate the owner of the site;but novice, naïve or off-guard users may not notice an incorrect domain, similarly to their lack of notice of whether the site is secure, as discussed in the previous subsection.

Furthermore, popular browsers are pre-configured with a list of many certification authorities, and the liabilities of certificate authorities are not well defined; also, the identity of the CA is displayed only if the user explicitly asks for it (which very few users do regularly, even for sensitive sites). As a result, it may not be very secure to use the URL or identity from the SSL certificate. Therefore, we prefer a more direct and secure means of identifying the provider of the web page, and – if relevant – of the CA, and not simply present the URL from the SSL certificate in the TrustBar.

TrustBar identifies, by default, both site and the certificate authority (CA) which identified the site, allowing users to decide if they trust the identification by that authority. The identification is based on the SSL server authentication, confirming that the site possesses the private key corresponding to a public key in a certificate signed by the given certificate authorities, which currently must be one of the certificate authorities whose keys are pre-programmed into the browser.

Figure 1.1: Screen-shots of secure sites with logo in TrustBar

Preferably, TrustBar identifies the site and authority by logo (or some other image selected by the user,e.g. a ‘my banks’ icon). However, since currently certificates do not contain a logo, TrustBar can also identify the site and authority by name. See Figure 1.1 for identifications by logo (in (b) and (c)) and by name (see (a)). TrustBar supports certificate-derived and user-customized identifiers for sites, by logo or name:

  1. Certificate-derived identification: Names are taken from the `organization name` field of the existing X.509 SSL certificates. Such names are presented together with the text `Identified by` and the name or logo of the Certificate Authority (CA) which identified this site. The site may provide the logo in an appropriate (public key or attribute) certificate extension. This may be the same as the certificate used for the SSL connection, or another certificate (e.g. identified by a <META> tag in the page). The logo may be signed by entities that focus on validating logos, e.g. national and international trademark agencies, or by a certificate authority trusted by the user.
  2. User-customized identification: The user can identify a logo for a site, e.g. by `right-click` on an image of the logo (which usually appears on the same page). Users can also select a textual site identifier (a `pet name’),presented by TrustBar to identify the site. Whenever opening a page with the same public key, TrustBar automatically presents this logo or pet name for the site.

By displaying the logo or name of the Certifying Authority (e.g. EquiFax or Verisign in Figure 1.1), we make use and re-enforce its brand at the same time. Furthermore, this creates an important linkage between the brand of the CA and the validity of the site; namely if a CA failed and issued a certificate for a spoofing web site,the fact that it failed would be very visible and it would face loss of credibility as well as potential legal liability.

Notice that most organizational web sites already use logos in their web pages, to ensure branding and to allow users to identity the organization. However, browsers display logos mostly in the main browser window, as part of the content of the web page; this allows a rogue, spoofing site to present false logos and impersonate as another site. One exception is the FavIcon, a small icon of the web site, displayed at the beginning of the location bar in most (new) browsers. Many browsers, e.g. [Mozilla], simply display any FavIcon identified in the webpage. Other browsers, including Internet Explorer, display FavIcon only for web-pages included in the user’s list of ‘Favorite’ web pages, possibly to provide some level of validation. However, since browsers display FavIcon also in unprotected pages, and come with huge lists of predefined favorite links, this security is quite weak. We believe that the logo or icon presented in the FavIcon area should be considered a part of the TrustBar and protected in the same manner.

Tags : , , , , , , ,

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Leave Comment