May 2, 2007
Safe Web Browsing
Description of Safe Web Browsing Mode (SBM)
Safe Web Browsing Mode (SBM) is where the browser can be placed into a mode which will only permit websites from a user’s personal SBM list to be accessed. This mode is intended for the user who wishes to be sure that they are at the intended known, trusted website before they exchange sensitive information. It addresses the needs of several of the use cases brought up in the WSC working group.
How this SBM might work
The user should be able to reliably create a personal list of websites that the user intends to routinely visit and will exchange sensitive information with, and wishes to be able to access in Safe Web Browsing Mode (SBM). These websites can only be selected from an approved list of websites that have gone to some lengths (e.g. compliance with special PKI technical requirements (see Part 1: Technical below), and undergoing a rigorous certification and compliance process) to allow it to be reliably distinguished from spoof sites. Examples of such certification steps include: being able to prove the website is from a trusted top level domain (e.g. .bank); or having the site credentials verified by an FI Bridge Authority; or verified by an EV where special verification and compliance steps have been taken to provide a guaranteed level of trust, such as including a verification process by an FI authority).
The user can built their list by either directly selecting sites from the SBM approved list, or starting out with an empty personal list and can add additional sites to the list as they are accessed and used, much as one now adds to their web favorite list, provided the site is on the approved SBM list. Alternatively, the user can choose to enable all the sites on the SBM approved list.
The user must take an active step to go into SBM. This will make it more difficult to spoof. This mode of interaction would be superior to either “good indicators” (e.g. green bars, locks, etc.) that currently are used to indicate the user is at a good website and/or is exchanging information with the website securely; or “bad indicators” (e.g. red alerts) that indicate the website is a spoofed or untrustworthy website. This is because the absence of these “indicators” (good or bad) is often over looked or ignored by many users. In addition, even poor spoofs of these indicators (indicators painted outside the chrome, or painted over the chrome) can fool enough users to make them not particularly useful.
This would be ideal for users that are willing to be careful about where they conduct financial transactions and want higher assurance that they are communicating with their FI. If users are somehow automatically placed into SBM mode without any action on their part, we are back to the same problem we are trying to avoid, which is getting users to recognize something that is “safe” (in this case SBM) based on some kind of visual or other cues.
When in SBM mode the browser will only permit websites from the user’s personal SBM list to be accessed. This prevents the user from being able to receive and/or log on to any site that is not on the SBM personal list. This creates a separation between the space where users conduct sensitive transactions from the space, and where they casually browse the internet. When in SBM mode, the browser will have a distinct look; and many features deemed dangerous will be turned off (e.g. see FSTC BMA document entitled “FSTC BMA Browser Recommendations”, applicable excerpts appended below), and the user can also test whether they are in SBM mode by trying to access a website not on their personal SBM list.
The goal of SBM mode to not to eliminate attacks like phishing, but to protect those who are willing to take proactive steps to avoid them. SBM mode would not be required, but be voluntary. Over time and through education, it is hoped that more and more users will elect to invoke SBM mode before they bank on-line or do other high risk transactions where personal information is exchanged. In fact, banks and other “trusted sites” could incent users who only access them on-line via SBM Mode (e.g. provide loyalty points, safety guarantees, fee discounts or higher interest rates).
To make SBM useful, three things must be true:
a. users must be in SBM mode before there is any possibility of providing bogus FI sites with information
b. users must be aware that they are in SBM
c. users must understand that only legitimate “trusted” websites will be accessible in SBM, and that it is therefore safe to provide information to sites that are accessible in SBM
d. users should be able to verify that they are at the intended "website" and that only legitimate "trusted websites" are accessible
Although the creation of a SBM mode is vitally important to the FI community where real dollars losses to our customers is at stake, the notion of safe browsing is inherent to many other communities; e.g. e-Bay, Amazon, your health care provider. So SBM should be developed so that any interested community can provide its own list of “trusted and compliant” websites that could be included in the SBM’s list of verifiable certified sites.
As with privacy, there may ultimately be different degrees of trust, associated with different communities of trust, that is related to the strength of the certification process and the relevant rules and policies governing the community with respect to security measures and behavior subscribed to by a participating members. However, to start with, we might keep things simple; either a site is trusted and included in the SBM list, or not.
It is worth noting that SBM could be built by adapting several current industry initiatives available today, such as Extended Validation Certificates and Card Space (or Info Space), which together achieves many of the SBM objectives. For example, Card Space allows a user to create a personal list of websites and requires the user to take an active step, and EV allows for stronger certification of certificates and allows this to be verified.
What would primarily be needed is integration of these with FI-certification by an FI authority and an FI EV type CA, with similar arrangements being made for other interested communities; and the extension of these initiatives or their open system equivalents, to other browsers. In fact, using these initiatives, appropriately adapted and coupled with an FI-certification step, and FI adoption and education, would go a long way to realizing this desired mode quickly and inclusively.
We view achieving SBM as a two part problem: Technical and User Interface
Part 1- Technical
The Secure Browsing Mode would need to be extremely difficult, if not impossible to fool into placing on its “trusted list”, or passing through an “untrusted site”.
One way to achieve this, would be to require the website to belong to one of a collection of special communities (e.g. FI, healthcare, anti-virus) that would be willing to be strongly certified as belonging to a trusted subclass (e.g. FI) through the use of a validated Bridge Authority and/or strongly certified EV community-type certificate, and to use PKI technology, to tightly bind its strong certification to its website (e.g. tight binding of the websites valid IP addresses and possibly other key content cues, and/or other features of its websites that cannot be mimicked by a spoof website, with digital fingerprints (hashes). This could include the websites of a firms partners/service providers, if the participating firm is willing to vouch for (cross-certify) its partners/service providers.
Another approach would be to create a special trusted top level domain which can only be accessed through DNSSEC protocol. This would require DNSSEC to be supported by the browser and/or the customer's ISP.
These measures should enable the web browser and OS to distinguish the website from other websites, no matter how close they look like the real website, even if their web page is a copy of the real web page sent from a spoofed website.
Several alternative technical approaches are currently being discussed that would be validated and tested.
The Safe Browser Mode would eliminate all threats except for two cases:
1. User fails to activate the safe browsing mode and mistakes the spoofed site for the desired site. We believe that if the majority of the legitimate community, such as banking, moves to delivering only over Safe Browsing mode and educating the consumers accordingly, this type of attack could be greatly minimized, just as customers are trained to protect their ATM card and their PIN.
2. The PC is taken over by key stroke loggers and Trojans which attempt to take over control of the PC and cause it to follow instructions for taking actions from malicious websites, such as going into SBM mode logging on with users credentials and instructing the bank to transfer funds, pay bills, etc. to fraud accomplices. This attack is out-of-scope in the sense that it needs to be addressed at the OS level, however, it could be minimized by a number of techniques. The most effective would be creating a secure trusted path, between a secure module in the PC (could be a small trusted kernel) and the Trusted Website; and providing transaction level security safeguards (e.g. securing the transaction instructions, along with use of alerts and required user confirmations).
Part 2 – User Interface
The simplest Safe Browser mode user interface would be to only allow “trusted sites” (those on the users personal safe web browsing list) to be seen and accessed when in Safe Browser mode. Even though the user could test the browser by attempting to access an untrusted site while in “Safe Mode,” it would be helpful if the Safe Browser Mode have a distinct look and feel to the user that would be difficult for a fraudster to impersonate. It could borrow from the look and feel of CardSpace and EV verification.
Alternatively, the Safe Browser mode could allow the user to access untrusted sites, but could prevent the user, when on any but those sites on the user’s Safe Web Browsing personal list, from logging on or exchanging any sensitive information with that site other than a member of the selected (or default) websites. This last user interaction method could parallel Tyler Close’s recent proposal.
Appendix I: Issues/Concerns
The best user interface is currently under review and debate and will be tested and validated. Listed below are some of the issues and concerns, surrounding the choice of user interface.
How is safe-mode substantially different from the "security zone" model employed (and unused) in current browser? Much of what we want is in the security zone model, but we want some additional things: e.g. be able to strongly link a website's IP address(s) to the desired website (e.g. with EV typed certs or DNSSEC or FI- (or other community) certified and signed websites hashed with the valid IP addresses). It is because there are these important bits and pieces already operational that I have hope we could see an implemented safe mode in relatively short order. Furthermore, the current security zone interface, such as in IE7, provide a long list of very technical terms that a user has to select, and its is somewhat cumbersome to change and reset. We would like something much simplier to invoke by the user, which by default eliminates when in safe mode all but the sites that both qualify and are selected by the user, as well as selecting a default security zone setting (most of the technical settings for safe mode are determined for the user, but if the user wishes he/she can see the settings).
Do you believe there are times when users don't want to be safe? Yes, when users want to go to social sites, browse the web, look for interesting content, converse with interesting people, they don't care about safety. On the other hand, there are some sites where the users wants to transact with very sensitive information and wants to be sure that they are on the correct site. In fact, if a user could easily switch back and forth, they would even be safer when they are not in safe mode because they would know they are NOT in safe mode and hopefully be much less trusting and willing to provide sensitive information when not in Safe mode. As a users travels around in the Wild Unsafe Web, they may find and establish a relationship with a web site that they want to know interact with more safely. If that site is appropriately certified and conforms to the needed technical security, the user can find that site is available for Safe Mode and add it to its Safe Mode list.
Creation of a separation between SBM and normal web browsing, comes at the price of a seamless transition from regular mode to SBM. This would eliminate the option of an FI sending legitimate clickable links to the user by email (although we could keep the links if they are rendered unoperable unless the user goes through a clicking sequence before clicking on the link). Most FI's claim not to do this anyway, so this shouldn't be too big an issue. Forcing the user to launch another application keeps them conscious of what they're doing (the task at hand is a sensitive transaction and they must be knowingly go into the separate mode to complete the task). There is concern that the business people who manage the consumer Internet channel at major banks will reject these conditions and their bedrock principle of “support all the popular web browsers” which is derived from a need to make online banking convenient and accessible to a very broad population of consumers. Any bank that unilaterally stops supporting today’s IE and Firefox browsers is simply giving away business to its competitors. That is why it is so critical that SBM mode be supported by the browser community and that going into SBM should be voluntary with education and incentives gradually causing a shift in user behavior.
But attitudes may be changing. Consider the results of the following recent study, entitled: “Customers want online ID protection more than reimbursement from banks” (See Appendix 1).
The distinction between safe browsing mode and regular mode must be absolutely clear to the user. It's been suggested that safe-browsing could take place in another tab or browser window, this solution would not draw a hard enough line between SBM and regular mode. A number of attacks we see now show that users can easily be fooled by windows that have the same look and feel. It's also important to keep in mind attacks like picture-in-picture, which would likely still be successful if SBM was simply another browser window [1,2,4].
Also, SBM should be careful to present the user with the minimal interface necessary to allow them to conduct their transactions (i.e. a space free of advertisements and other noise on the page). Stripping the safe-browsing mode off all unnecessary information would help reduce the number of things an attacker can exploit, but the introduction of a stripped online banking interface would likely imply an education period. The users would have to be convinced that they are in fact on the correct site and communicating with their bank even though most of the graphics and links they're used to seeing are absent.
 Dhamija, R., Tygar, J., and Hearst, M. "Why Phishing Works" In Proceedings CHI. (2006)  Jackson, C., Simon, D., Tan, D., and Barth, A. "An Evaluation of Extended Validation and Picture-in-Picture Attacks" In Proceedings Usable Security. (2007)  Shne"iderman, B. "Designing the User Interface".  Wu, M., Miller, R., and Little, G. "Web Wallet: Preventing Phishing Attacks by Revealing User Intentions" Symposium on Usable Privacy and Security. (2006)
Appendix Customers want online ID protection more than reimbursement from banks The majority of Internet users are more concerned with getting identity safeguards for online banking than being reimbursed for losses, according to a US survey conducted by Javelin Strategy & Research and commissioned by Authentify. Over half (58%) of the 2781 respondents surveyed said incurring a financial loss was not their primary concern about Internet banking. Instead loss of personal information and the possibility that fraudsters would commit financial fraud in their name were the two main worries. The research also found that the vast majority of respondents - 90% - are willing to sacrifice convenience for stronger security protection for online banking. Over three quarter (78%) of respondents wanted IDs to be verified using real-time authentication mechanisms in the event of suspicious account activity. Of these, more than 30% selected interactive phone calls or SMS text alerts as their preferred means to monitor transactions. Around eight per cent favoured traditional methods that delay a transaction until further authentication can be obtained by bank staff or written notification. Commenting on the research, Stephen Knighten, a statistical analyst at Javelin, says: "These findings demonstrate that the financial services industry must go beyond zero liability protection and offer more comprehensive identity safeguards to gain the trust of consumers."
Appendix 2 - FSTC BMA Browser Recommendations
Below are included some of the FSTC recommendations that are applicable for the Safe Browsing Mode and that are within the scope of WSC
A stronger UI, makes it very clear whether or not the user is visiting a "legitimate site (see below for further discussion of what constitutes legitimacy), and that requires explicit user acton (e.g. overriding a warning) to visit a site that is questionable. The enhanced UI will go well beond the existing locked padlock icon and display strong indicators that
- The communications channel is "adequately secure (i.e. that the encryption technique and cipher strength meet policy guidelines b. The site is who it claims to be (i.e. the information presented by the site corresponds to identifying information contained within the site's certificate) c. The site's certficate is certified by "strong" certification hierarchy, whose roots are a small subset of the root CAs distributed with the browser, and whose certification policies are developed by the financial services industry
- Make it easy to view and understand the contents of a server cert b. Make error messages related to revoked and expired certs clear and actionable c. Display warning when a hostname is resolved via local HOST file instead of DNS d. Show [security context] in all modes including full screen
- a Make UI for adding new root cA more understandable b Make process for requesting and installing certs/keys easy and seamless
Strengthen Browser against Local Attack
- Make it impossible for client scripts, controls, add-ons, or plugins to alter address bar or [security context displays]
Local browser-based defense against spoofed sites
- Checking for server cert revocation on by default b. Block https access when hostnames in the server cert and URL don't match. No confusing dialog box c. Block https access when server cert not issued by a trusted RCA. No confusing dialog box d. Don't give uses the option to disable cert revocation or expiration checks