Posts Tagged ‘URL

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 : , , , , , , ,

Phishing Email

Phishing emails are crafted to look as if they’ve been sent from a legitimate organization. These emails attempt to fool you into visiting a bogus web site to either download malware (viruses and other software intended to compromise your computer) or reveal sensitive personal information. The perpetrators of phishing scams carefully craft the bogus web site to look like the real thing.

For instance, an email can be crafted to look like it is from a major bank. It might have an alarming subject line, such as “Problem with Your Account.” The body of the message will claim there is a problem with your bank account and that, in order to validate your account, you must click a link included in the email and complete an online form.

The email is sent as spam to tens of thousands of recipients. Some, perhaps many, recipients are customers of the institution. Believing the email to be real, some of these recipients will click the link in the email without noticing that it takes them to a web address that only resembles the address of the real institution. If the email is sent and viewed as HTML, the visible link may be the URL of the institution, but the actual link information coded in the HTML will take the user to the bogus site. For example

visible link:

actual link to bogus site:

The bogus site will look astonishingly like the real thing, and will present an online form asking for information like your account number, your address, your online banking username and password—all the information an attacker needs to steal your identity and raid your bank account.

What to Look For

Bogus communications purporting to be from banks, credit card companies, and other financial institutions have been widely employed in phishing scams, as have emails from online auction and retail services. Carefully examine any email from your banks and other financial institutions. Most have instituted policies against asking for personal or account information in emails, so you should regard any email making such a request with extreme skepticism.

Phishing emails have also been disguised in a number of other ways. Some of the most common phishing emails include the following:

  1. fake communications from online payment and auction services, or from internet service providers – These emails claim there is a “problem” with your account and request that you access a (bogus) web page to provide personal and account information.
  2. fake accusation of violating Patriot Act – This email purports to be from the Federal Deposit Insurance Corporation (FDIC). It says that the FDIC is refusing to ensure your account because of “suspected violations of the USA Patriot Act.” It requests you provide information through an online form to “verify your identity.” It’s really an attempt to steal your identity.
  3. fake communications from an IT Department – These emails will attempt to ferret passwords and other information phishers can use to penetrate your organization’s networks and computers.
  4. low-tech versions of any of the above asking you to fax back information on a printed form you can download from a (bogus) web site.

Tags : , , , , , , , ,