Browser Security Handbook

• 1 Introduction
  • 1.1 Motivation
  • 1.2 Theses
  • 1.3 Browsers
• 2 Privacy
• 3 Browser Extensions
• 4 Tabnabbing Attacks
  • 4.1 Introduction
  • 4.2 Requirements
  • 4.3 Combinations of attacks
  • 4.4 Countermeasures
  • 4.5 Desktop versus Mobile
  • 4.6 Comparison
• 5 CSS History Attacks
  • 5.1 Introduction
  • 5.2 JavaScript method
  • 5.3 Pure CSS method
  • 5.4 Practical Application
  • 5.5 Performance
  • 5.6 Countermeasures
  • 5.7 Comparison
• 6 Graphical User Interface
• 7 Transport Layer Security
  • 7.1 Introduction
  • 7.2 Supported SSL Versions
  • 7.3 SSL Implementations
  • 7.4 Cipher Suites
• 8 Certificates
  • 8.1 Introduction
  • 8.2 Valid Certificates
    • 8.2.1 Certificate handling in mobile browsers
    • 8.2.2 Potential Risks
    • 8.2.3 Guidelines for valid certificate handling
  • 8.3 Invalid Certificates
    • 8.3.1 Expired Certificates
    • 8.3.2 Self-Signed Certificates
    • 8.3.3 Handling in mobile browsers
  • 8.4 Indicators
  • 8.5 Attacks
  • 8.6 Comparison
• 9 Mixed Content
  • 9.1 Secure connection, insecure content
  • 9.2 Transitions
  • 9.3 iframes
  • 9.4 Conclusion
  • 9.5 Comparison Chart
• 10 Conclusions
• 11 Appendix
  • 11.1 Privacy settings and options
  • 11.2 Certificate indicators
  • 11.3 Certificate details
• List of Figures
• List of Tables
• Bibliography

Google's Browser Security Handbook [1] offers a one-stop reference about security features of the most common web browsers for developers, engineers and security researchers. Microsoft Internet Explorer 6, 7 and 8, Mozilla Firefox 2 and 3, Apple Safari, Opera and Google Chrome are covered. The document also includes partial coverage of the native browser of Android OS, Google's operating system for mobile devices, but other than that lacks information about the many mobile browsers on the market.

This could be explained with the very small market shares of mobile browsers in the past with only 0.4% of hits originating from mobile browsers in the first quarter of 2009. But this number has since been constantly increasing and in Q4 2010, 3.2% of all requests came from mobile browsers [2]. With mobile devices like Apple's iPhone becoming more and more widespread, so does the number of people accessing the internet on the go. Especially Google's mobile operating system "Android" has been pushing the numbers since its introduction in 2008 and its native browser has since become the second most used mobile browser behind Safari Mobile with a share of about 19% amongst all mobile browsers in February 2011 [2].

With the rise of mobile browsers, new security requirements come up as well. Comfort features like hiding the GUI to show content full screen make attacks like visual spoofing possible. Or, with being carried around all the time, there is a risk of losing mobile devices and private data stored on them, like passwords or cookies, contrary to using only stationary desktop computers.

This thesis aims to offer information about security-relevant properties of several mobile browsers. The goal is to create a handbook that is similar to Google's Browser Security Handbook.

The information found in this thesis is for the most parts based on information from three bachelor theses, which examined security aspects of four mobile browsers in total. More detailed information about these theses and observed browsers can be found on the following two pages.

It should be noted that most mobile browsers are based on their desktop equivalents, and therefore offer "hidden" possibilities to access certain features like debug consoles or also security settings through about:* or chrome:// URLS. Since these are only usable by (or even known to) expert users, their existance is not considered for the observations in this thesis.

For the most parts, this handbook is based on information from three bachelor theses about mobile browser security. All were written at the Horst-Görtz Institute at Ruhr-University Bochum, Germany, and, like this work as well, supervised by Florian Kohlar. They are, in chronological order:

"Funktionen und Sicherheit mobiler Browser auf dem Nokia N900"
("Functionality and Security of mobile Browsers on Nokia N900")
Michael Uhlemann, September 26th 2010

"Funktionen und Sicherheit mobiler Browser: Der native Browser des Nokia X6"
("Functionality and Security of mobile Browsers: the native browser of Nokia X6")
Oliver Domke, October 7th 2010

"Security Analysis of Mobile Safari on iOS 4"
Henning Velthaus, October 28th 2010

Above theses observed a total of four mobile browsers on three different mobile phones. While not looking at the underlying hardware or operating system, this handbook is based on the information found in the theses above about the following browsers.

MicroB

MicroB is based on Mozilla's Gecko engine and is basically a modified version of Firefox Mobile, made by Nokia specifically for phones running the "Maemo" operating system. It is the native Browser of N800, N810 and N900 phones and can not be removed.

Version: 1.7.4.8

User Agent (unique identification string sent by the browser in a HTTP header field, containing information like product name, version and operating system): Mozilla/5.0 (X11; U; Linux armv71; de-DE; rv:1.9.2b6pre) Gecko/20100318 Firefox/3.5 Maemo Browser 1.7.4.8 RX-51 N900

Firefox Mobile

Firefox Mobile is a mobile variant of the popular Firefox desktop browser. It is based on Firefox 3.6.5, which uses the Gecko engine version 1.9.2.5. At the time of writing the bachelor thesis, Firefox Mobile was only available for N810 and N900 phones..

Version: 1.1

User Agent: Mozilla/5.0 (X11; U; Linux armv71; de-DE; rv:1.9.2.5) Gecko/20100614 Firefox/3.6.5pre Fennec/1.1

S60

The S60 is the native browser of the Nokia X6 mobile phone and can not be removed. It is based on the KHTML/Safari engine and was adapted for the Symbian operating system by Nokia.

Version: 3.0

User Agent: Mozilla/5.0 (SymbianOS/9.4 Series60/5.0 NokiaX6-00/20.0.005; Profile/MIDP-2.1 Configuration/CLDC-1.1) AppleWebKit/525 (KHTML, like Gecko) Version 3.0 BrowserNG/7.2.3

Mobile Safari

Mobile Safari is the native browser of the iPhone, iPad and iPod Touch and can not be removed. Although it was named after the Safari browser for Mac OS X, it is not a port, but a prorietary browser developed specifically for iOS, based on Apple's WebKit engine. It is open source and licensed under the GNU Lesser General Public License.

Version: 3.1.1

User Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5F136 Safari/525.20¹

A standard feature of modern desktop browsers is fine-grained control over the collection and storage of data that affects the user's privacy. This includes settings to allow or disallow collecting of data like cookies, browser history entries, the browser cache or form field data, but also management of this private data after being collected, involving the option to delete single data or certain types of data on the whole.

Storing all kinds of security sensitive data on a mobile device means a much more present security problem compared to desktop browsers, simply because the risk that these devices are lost or stolen is much higher. Everyone with physical access to a mobile device, for whatever reason, might for example be able to log into the owner's social network account, read his emails or even get control over his bank account. If the necessary login data or cookies are stored on the device, that is. Therefore, options to delete private data manually or automatically and settings to disallow storing of cookies, form values and such altogether are mandatory and particularly important on mobile browsers.

By default, the S60 browser stores all cookies, visited sites and form data including passwords. Before passwords are saved, the user is prompted to allow it ("Save your login details for this page?"). It is possible for the user to delete the stored data, but only all saved items of each type (cache, cookies, history and form/password) at once; it is not possible to select individual items for deletion, like a single password. See the appendix (11.1) for screenshots. It has to be said that the standard settings of the S60 browser do not put much emphasis on privacy, and only few corresponding settings are available to the user. Storing of cookies can be either allowed or not and the user can choose to store form data, form data plus passwords or none of both. Another setting allows the user to turn off saving of "recently visited pages". This does not refer to the browser history, though, only to sites visited during the current browser session and is only used for the browser's "back" button. These are stored in addition to the usual browser history, and are deleted when the browser is closed.

The situation in MicroB is similar. It also stores the user's browsing history, cookies and passwords by default. The user can delete fives types of private data in bulk; browsing history, cache, cookies, passwords and authenticated sessions. Deleting individual stored items like a single password is not possible. Furthermore, there are settings to disable the automatic saving of passwords and cookies.

Privacy options are even more scarce in Firefox Mobile. Two settings let the user allow or disallow saving of cookies and passwords. Right below, a button allows clearing of all private data at once. This includes cookies, cache, passwords, the browsing history and authenticated sessions.

Mobile Safari stores the browsing history, cookies, cache and form data including login credentials by default. The latter is handled by the browser's "AutoFill" function, which can be turned off. By default, Mobile Safari only accepts cookies from visited sites, but not those from sites loaded in iframes or via scripts. The user can also choose to allow all cookies, or none at all. It is possible to delete the stored browsing history, cookies, cache and (in the "AutoFill" menu) passwords. Each of the four types of data can only be deleted in bulk, it is not possible to delete only specific data like a single cookie.

None of the above browsers features a private mode that allows for only temporary saving of private data. Furthermore, none allows the deletion of flash cookies. Those are not bound to the browser, and have to be deleted by hand, which only advanced users can do or even know about.

Illustration 1: [Screenshot] Security settings of Firefox Mobile (Nokia N900)

The above screenshot shows the (very basic) security settings which Firefox Mobile offers to the user. Additional screenshots showing privacy settings and options of mobile browsers can be found in the appendix.

The observed mobile browsers offer much less control over private data than desktop browsers. At the same time, as described earlier, the presence of private data on a mobile device that is carried around is a much higher risk than on a stationary device, like a desktop computer.

The following table sums up the observations made in this chapter.

Plugins and add-ons are both terms that describe extensions to the usability of a browser. The line separating those two types of extensions is not always very clear, but the difference can roughly be broken down to the following [3].

A plugin extends a browser by new capabilities and is basically a piece of independent software working inside a browser. The most popular example for a plugin is Adobe Flash, which enables browsers to display flash content. The Adobe Flash plugin can be found on 99% [4] of browsers, independent of type and underlying operating system and therefore is a widespread potential security risk. More on this later.

Add-ons on the contrary extend and modify a certain browser's capabilities. They add new functionality to it or modify the way in which content is displayed. One popular example for an add-on is Adblock Plus, which filters a website before it is displayed to the user to remove advertisements by checking their source or surrounding tags against blacklists. They are pieces of software that are usually developed specifically for one browser.

Illustration 2: [Screenshot] Add-on Manager of Firefox Mobile 1.1 (Nokia N900)

The comparison chart at the end of this chapter shows exactly which of the two is supported by which browser. Modern mobile web browsers support both plugins and add-ons, although those have to be specially programmed; extensions from respective desktop browsers can not be used.

Plugins and add-ons are undisputably an essential feature of modern browsers, offering a much enhanced and personalized browsing experience to the user. This particularly is the case for full-fledged desktop browsers, but there are also extensions for mobile browsers, which are potentially important to many users, for example AdBlock for Firefox Mobile.

The difference of extensions for desktop browsers to those for mobile browsers is that the latter are not usually implemented by the developers themselves, but are adapted versions that are offered by phone manufacturers. Therefore, there often is a notable delay in releases and extensions for mobile browser can be outdated and contain known security flaws for long periods of time.

With all the additional user comfort on one hand, potential security risks arise from browser extensions on the other hand. As an important example, Adobe Flash has to be mentioned again. At the time of writing of the underlying thesis by Michael Uhlemann, the latest available version of Flash for the MicroB browser was 9.0 r260, which has known security issues that "could cause a crash and potentially allow an attacker to take control of the affected system." [4]. Mobile Safari on the other hand does not support Flash since for security reasons Apple decided against it for all their mobile platforms.

To assure that users are always running the latest version of a plugin instead of an older version with known attack vectors, automatic updates or at least automatic checks for updates and presentation of these to the user is a desired feature.

Despite the potential security flaws, add-ons can also provide additional security. One example is NoScript for Firefox Mobile, which can prevent attacks that rely on the use of JavaScript, like Visual Spoofing or Tabnabbing attacks. These two attacks will be discussed in detail in the following chapters.

When a user wanted to have multiple HTML documents open at once in earlier desktop browsers, a separate browser instance (or "window") was started for every single one of them. As browsers advanced, so-called "tabbed browsing" revolutionized this by allowing the user to open multiple documents in the same window, between which he (he or she, but for the sake of simplicity it will be only "he" from now on) could switch through little "card indexes" (called "tabs") at the top of the screen. At the same time, the possibility to open several browser instances was kept.

In all four observed mobile browsers, it is not possible to open more than one browser instance ("window"), but all allow multiple tabs. One exception is that tabs in the S60 browser (which misleadingly calls them "windows") are practically unusable, because manual switching between them is not possible.

When a mobile browser allows multiple tabs to be opened as well as manual switching between them, a so-called Tabnabbing attack is possible. This attack, which was first presented by Aza Raskin [5], is about "kidnapping" a tab, hence the name, and is a new approach to classic phishing attacks. What it does is altering the content, title and favicon of a website in the background after the user switched to another tab or opened up a browser menu. This case can easily be detected by a malicious website through the window.onblur JavaScript event. Once it fires, a timer is set that eventually calls a script that alters, replaces or overlays the original site content to make it look like a different site and replaces the favicon. One example would be a recreation of the PayPal login page displaying a message that the user's session has timed out and asks to re-enter his login data to log in again.

The base assumption of Tabnabbing is that a user can easily lose overview if he has several tabs open at the same time. If the user can be tricked into believing that he opened the site that is being faked and enters his login credentials, those can be intercepted by the attacker. The data could then be forwarded to the real site, so the user would not even notice the fraud.

Allowing multiple open tabs is yet another feature that is meant to enhance user comfort, but on the other hand opens opportunities for malicious websites to attack a user through the browser.

It will later be shown that mobile browsers are particularly vulnerable to tabnabbing attacks.

The full list of requirements for performing a successful Tabnabbing attack can be found below.

• JavaScript has to be enabled in the user's browser. Although, a non-dynamic, non JavaScript-based variant of the Tabnabbing attack has been developed by Eitan Adler [6].
• If no visual spoofing attack has been performed on the address bar, the user has to overlook that the site URL differs from that of the website that is being faked. But since many mobile browsers show the site title instead of its URL, this is not a problem for the attacker.
• If a faked site should normally be encrypted and no visual spoofing attack has been performed to recreate SSL & certificate indicators, the user has to overlook the missing indicators.
• The language of the faked site has to meet the user's setting. With a little bit of extra work on the attacker's side, the user's origin (and therefore language) can be detected and a localized version of the faked website can be displayed, though.

To increase chances of a successful Tabnabbing attack, it can be combined with other attacks.

In case of the aforementioned example of the PayPal login page, it for example might make sense to use visual spoofing to display a fake address bar that simulates a SSL secured connection to PayPal (described in chapter 6). Since this is a browser specific attack, it would be necessary to detect a user's browser and display fake GUI elements specifically made for each one. Depending on an attacker's reasons for a Tabnabbing attack, this might not be worth the effort.

Furthermore, a CSS History Hackcould be performed to determine if a user has ever been to the site that an attacker wants to mimic. If he has not, it would make no sense to perform the attack, since the user would most likely not fall for it. Details on CSS History Hacks can be found in chapter 5.

Under the assumption that the browser allows (comfortable handling of) multiple open tabs, there are only few possible countermeasures against Tabnabbing.

One that has been mentioned by Aza Raskin is the Account Manager [7] for Firefox. The Account Manager, which is going to be integrated into Firefox browsers, is a new concept for online authentication. The idea is to let the browser handle authentication to websites automatically in contrary to the process of letting the user type in and send his username and password manually. In the current state of development, all that is needed to "teach" a browser how to log in to a particular site is to provide a small JSON file, a so-called Account Manager Control Document (AMCD).

This fully automated approach is supposedly more secure and user friendly than the classic concept of manually sending login credentials.

Another (obvious) solution would be to disable the window.onblur event altogether.

Both desktop and mobile browsers are vulnerable to Tabnabbing attacks. It could be assumed that a user has much less open tabs on mobile browsers compared to desktop browsers and should therefore not as quickly loose overview over those. At least that is the theory, but actually the opposite is the case due to the fact that tab management elements are usually hidden from the screen while a user is browsing a website. So, on mobile browsers

1. the user has no chance to eye-witness the transformation of a tab and
2. the address bar, which would be the only clue that a site is not what it is pretending to be is usually not on screen and could even be faked through visual spoofing.

The only one out of the 4 tested mobile browsers, that is not prone to Tabnabbing attacks, is the S60 browser. Because it does not allow manual opening of new tabs (which practically means no support for multiple tabs), it is much less vulnerable to Tabnabbing attacks. The only possibility for a successful Tabnabbing attack on the S60 browser opens up if the user switches to another application (and does not close the browser), while viewing a malicious site. Since the window.onblur event gets triggered in that case, the site would change in the background and be presented to the user the next time he opens up the browser.

One comfort feature that has been implemented in web browsers since the standardization of Cascading Style Sheets with CSS1 in 1996 is the detection and colorization of visited and unvisited links through CSS pseudo classes. By default, browsers color unvisited links blue, while visited links are purple, and so help the user determine which sites he has already visited and which he has not. Of course, since being part of the CSS standard, the necessary pseudo classes, namely :visited for visited and :link for unvisited links, are also implemented in mobile browsers.

Illustration 3: [Screenshot] Link styling on Google search results page (Firefox Mobile 1.1, Nokia N900)

This is arguably a helpful feature for the user, but also opens up the gates for malicious websites to gather information about the user's browsing history. To achieve distinguishing visited and unvisited links, a browser has to keep record of the user's activity on the net and store the exact URLs of all visited sites in the so-called browser history. Now, while it is not possible to simply copy data from the browser history, there are ways for a server to find out if a client has been to a particular site. Below, two methods of this attack, which has been known since the beginning of the millennium [8], are shown.

The JavaScript based CSS History Hack makes use of the ability of JavaScript to access computed CSS styles of elements through the getComputedStyle() function.

To prepare the attack, a certain attribute has to be assigned to visited links through CSS and the respective :visited pseudo class to distinguish between visited and unvisited links. For example, unvisited links could be assigned the color red:

Once the malicious site has loaded, a link ("a") element gets created with the createElement() JavaScript function. The script then cycles through an array of URLs that an adversary wants to check against the user's browser history and each gets copied to the "href" (which defines the link target) attribute of the previously created link element. The link style is finally checked for the color red with the getComputedStyle() function and, on a successful check, the URL is copied to an array, which holds all visited sites.

After cycling through all defined URLs, the array of visited links has to be passed to the server as the final step. The XMLHttpRequest JavaScript object can be used for this to send a POST request containing the array in the background.

The following example JavaScript source code is based on sample code from http://wtikay.com. Note that the array "visited" has to be converted to JSON format before being passed to the XMLHttpRequest object. In order to keep the example well-arranged, it does not include the needed function, but a link to one is provided.

Since the link element gets added and modified after the site has loaded, it is not part of the site's Document Object Model (DOM) tree and does not have to be rendered. Therefore, this method is very quick.

Another implementation of the attack does not rely on JavaScript, but uses pure CSS. It builds on the idea of assigning background-image CSS style values to visited links through the :visited CSS pseudo class. What is loaded through the background-image attribute is not an image, though, but a PHP script, which sends back data to the server. This method requires adding all links that are going to be tested to the site source and linking an individual style value to each link through unique ids that are assigned to the links. If no link text is specified, those links are invisible to the user.

In contrast to the JavaScript based method, a DOM element has to be created and rendered for each link that is checked.

The main challenge for practical usage of the CSS History Hack is the question which URLs the client's browser history should be checked against. Since it works not only with top level URLs (like http://www.google.com), but also any possible sub level URL (like http://www.google.de/search?q=search+term), the possible values to poll for are infinite. Certain tricks can be applied to increase the likelihood of successful checks.

A good algorithm could, for example, only scan for top level URLs at first. In a second step, it would scan for any sub level URLs only for sites that were detected as visited. Additionally, to generate lists of all available sub level URLs, sites could be crawled beforehand by a script that recursively follows all internal links and so creates sitemaps.

To target as many people as possible with the highest possible performance, both methods of the CSS History Hack can easily be combined. Since being the faster one, the JavaScript method would be the first choice, with the pure CSS solution jumping in as a fallback if JavaScript is disabled. The HTML tag <noscript> can be used for this, as its content is only executed if JavaScript is disabled.

The CSS History Hack is also a great tool in combination with other attacks. For example it can be used to increase chances of a successful phishing attack like Tabnabbing, as mentioned in chapter 4.

A lot of data can be gathered about a user beyond the sites he has been to, depending on how specialized an attack is. This goes as far as learning a user's address data, real name or other personal data by specifically checking for URLs of social networks for example [9]. Repressive regimes could use it to identify potential enemies by checking for sites of human rights activists or similar. (Although there are easier ways to do so with local internet service providers under their control.) As a more positive, but still malicious example, online shops could monitor, which competitors someone has been to, which articles he has looked at and such, and adjust the own offering accordingly. For example, items of known interest for a user could be advertised on the front page as a special deal, possibly with slightly lower prices than competitors are asking.

Illustration 4: [Screenshot] "What the Internet knows about you" (wtikay.com) sample implementation of hybrid JavaScript/Pure CSS History Hack (Firefox Mobile 1.1, Nokia N900)

As already mentioned, the CSS History Hack is performing very well. Using optimized algorithms, Artur Janc and Lukasz Olejnik [9] showed that up to 30,000 links can be checked using the JavaScript based method and even up to 50,000 links per second using the pure CSS method. Numbers strongly depend on a variety of parameter like the algorithm used, the browser or the number of checked elements.

Illustration 5: Performance of the CSS History Hack using the JavaScript (left) and pure CSS (right) methods

Due to weaker hardware specifications, the attack performs worse on mobile browsers compared to the above numbers, which all refer to desktop browsers. Firefox Mobile running on Nokia N900 as an example can check about 1,250 links per second using JavaScript, and only 200 per second using pure CSS.

• Turning off the browser history is obviously the most secure countermeasure against the CSS History Hack. This, however, goes along with a severe loss of user comfort and therefore can not be considered a real alternative.
• When setting the browser to delete the history after a session or by using the private browsing mode, a history is only created temporarily and discarded after a session (i.e. when the browser or private browsing mode is closed). Both possibilities lead to practically the same results as above, though.
• The most practically applicable countermeasure appears to be disabling the :visited CSS pseudo class, which would cause only a small loss in user comfort. This, however, can only be done through about:config and the setting layout.css.visited_links_enabled in Mozilla-based browsers.
• There is also the "SafeHistory" plugin for Firefox allows offsite visited links to be marked only if the browser's history database contains a record of the link being followed from the current site.³
• Upcoming new versions of Mozilla Firefox and Google Chrome will include countermeasures that close the gates for the CSS History Hack. The included fix lets the getComputedStyle() function always return the "unvisited" status to close the JavaScript based method, and always follow URLs specified by the CSS background-image property, regardless of the rule being triggered or not.

On Desktop browsers, the user always has the user interface in sight and is able to quickly verify the URL of the site he is looking at, the protocol used, server certificates and other security relevant information. For mobile browsers on the contrary, it is a common behavior to fade out graphical user interface elements such as the address bar after a site has completely loaded. This aims at using as much of the sparse screen space as possible. While this may enhance the user experience, it can be a severe security problem and open up opportunities for visual spoofing attacks.

For example, it is possible to create almost pixel-perfect deceptive copies of a browser's GUI elements or dialogues. It has to be distinguished between two main tasks: visually recreating those elements and mimicking their behavior. While the visual part can be easily achieved using CSS (Cascading Style Sheets) and images, JavaScript in addition can be used to mimic the elements' behavior. This, however, is a little bit trickier, as some things have to be taken into account.

One of these things is the screen alignment, which usually automatically adjusts to the way the user is holding his phone - horizontally or vertically. So there has to be a script that detects alignment changes, for example by monitoring the screen height and width, and automatically adjusts the fake GUI.

In addition, screens size monitoring can be used to dynamically adjust the fake GUI to use 100% of the screen's width. Since the real browser UI obviously is always the same size, it is possible for the user to detect the fraud when he zooms in to the website and sees the fake GUI change size as well.

Furthermore, the GUI is usually faded out a few seconds after a website has loaded, so a script has to set a timer to show the fake elements as soon as the real ones disappear.

The conclusion of this is that it is possible to recreate mobile browser GUI elements. If a user mistakes those fake elements for real, he can, for example, be made to believe that he is communicating through a TLS secured channel, while he is actually not.

The following screenshots show a fake PayPal login page including a fake GUI of the Firefox Mobile browser. Note the absense of any real browser GUI elements which could expose the fraud to the observing user. The MicroB browser for example shows a white arrow in the bottom right side, which acts as a button to bring back up the GUI elements. It it always visible when the UI is faded out and cannot be overlaid by any elements of the displayed website. See the third of the following screenshots for an example.

Illustration 6: [Screenshot] Fake PayPal login page and respective fake GUI (Firefox Mobile 1.1, Nokia N900)

Illustration 7: [Screenshot] Fake PayPal login page and respective fake GUI, showing certificate information (Firefox Mobile 1.1, Nokia N900)

Illustration 8: [Screenshot] Arrow to bring back up browser GUI (S60, Nokia X6)

Concerning the above observations regarding Visual Spoofing attacks, there are a few things, which designers of mobile browser user interfaces should keep in mind:

• At least one always visible button (for example an arrow) to bring up the address bar and such should be provided. Malicious websites must not be able to overlay this button.
• It might furthermore help to not fade out the UI automatically, but let the user do it to make sure that it is his explicit wish to hide it.
• The address bar should in some form show the protocol used, so a user can easily detect whether he is using a secured connection or not.
• Some mobile browsers don't show URLs at all, but only the title of the currently viewed site. This greatly benefits fishing attacks and should be avoided; the user should easily be able to see the (full) site URL.
• There should be some way to determine the URL behind a hyperlink. This could for example be done through a status bar or the URL could be shown upon touching and holding the link for a while. This not being possible would greatly benefit malicious activity like fishing attacks as well, since anything could be hidden behind a link with no chance for the user to check a link location beforehand.

Secure Sockets Layer (SSL) is a cryptographic protocol developed by Netscape [10]. It provides communications privacy over the Internet and is working on the Transport Layer of the TCP/IP model [11], usually encrypting TCP messages, which encapsulate Application Layer protocols like HTTP.

In February 1995, SSL saw its first public release with SSL 2.0, version 1.0 was never released. Due to a number of security flaws in version 2.0, SSL 3.0 was released in 1996. Version 3.0 was the last version and by today's standards it is no longer considered secure, due to the key derivation process fully depending on MD5.

In January 1999, the TLS Working Group released the Transport Layer Security (TLS) 1.0 protocol specifications [12]. It is based on SSL 3.0 and identifies itself as SSL 3.1. It is not interoperable with SSL 3.0, but contains a mechanism to downgrade a connection to 3.0. TLS is the de facto standard for client-server-security, with TLS 1.2 being the latest approved version.

Security Features of TLS:

• Privacy through encryption of messages
• Authentication through certificates
• Message Integrity through digital signatures

Updates to TLS have been released with TLS 1.1 (SSL 3.2) in April 2006 [13] and TLS 1.2 (SSL 3.3) [14] in August 2008. These further improve security of TLS encrypted messages by, for example, updating hashes from a MD5/SHA-1 combination to SHA-256, adding security against Cipher Block Chaining (CBC) attacks, or by introducing new, AES-based Cipher Suites.

Necessarily prior to any TLS secured communication is the TLS handshake protocol. It includes server (and, in rare cases, also client) authentication, negotiation of SSL version and Cipher Suite to use and exchange of key material.

The following figure illustrates the process:

Illustration 9: Full TLS Handshake⁴

The single messages consist of the following:

• Client Hello (0x01) (Client → Server)
  • Highest SSL version number supported by client (2 Byte)
  • Client Challenge (32 Byte random number)
  • Session ID (Optional) (32 Byte)
  • List of Cipher Suites supported by client
  • List of compression routines supported by client
• Server Hello (0x02) (Server → Client)
  • SSL version to be used for this connection (2 Byte)
  • Server Challenge (32 Byte random number)
  • Session ID (32 Byte)
  • Cipher Suite to be used for this connection (2 Byte)
  • Compression routine to be used for this connection (2 Byte)
• Certificate (0x0B) (Server → Client)
  • X.509 Certificate
• Server Key Exchange (0x0C) (Optional) (Server → Client)
  • Public key of server
• Client Certificate Request (0x0D) (Optional) (Server → Client)
  • Request message for the client's certificate
• Server Hello Done (0x0E) (Server → Client)
  • Closes Server Hello message
• Client Certificate (optional) (Client → Server)
  • Client's certificate
• Client Key Exchange (0x10) (Client → Server)
  • Depends on selected key exchange method:
    • RSA (Encrypted Key Transport):
      (Highest SSL version of client || 46 Byte pre-master secret)^e mod n
    • Diffie-Hellman:
      g^e mod n
• Certificate Verify (0x0F) (optional) (Client → Server)
  • Hash of all previous communication
• [Change Cipher Spec] (Client → Server)
  • Means a key has been computed and will now be used
• Client Finished Message (0x13) (Client → Server)
  • PRF(master secret || "client finished" || hash MD5 || hash SHA-1)
• [Change Cipher Spec] (Server → Client)
  • Means a key has been computed and will now be used
• Server Finished Message (0x13) (Server → Client)
  • PRF(master secret || "server finished" || hash MD5 || hash SHA-1)

Due to the structure of the handshake procedure, it is effectively the server that determines which version of SSL (and which Cipher Suite) will be used in upcoming communications. So if older, insecure SSL versions are supported by the browser, it is possible for a malicious server to force it into using these. Forcing a client into using SSL 2.0 only requires a small modification to the httpd-ssl.conf configuration file of the Apache server, changing the default setting SSLProtocol all to SSLProtocoll -all +SSLv2. On the default setting, the server would choose the highest SSL version the browser supports. The modified setting disallows "all" and allows only SSL 2.0, so any browser that supports it would be forced to use it.

Because of the above observations, all modern desktop and mobile browsers should support TLS to establish secure communication channels over the Internet. SSL 2.0 and 3.0 on the other hand have security flaws and should not be supported or at least be deactivated.

There are several open source implementations of the SSL and TLS protocols like OpenSSL, GnuTLS or NSS. Some mobile browsers use native implementations, though.

MicroB and Firefox Mobile are both using the Gecko engine, which includes the NSS library [15].

S60 uses a native, embedded solution based on the CSecureSocket interface [16] of the underlying Symbian OS.

The Safari browser family, including Mobile Safari, uses the same SSL implementation on all platforms [17], which is OpenSSL.

A cipher suite is a combination of algorithms used to negotiate the encryption keys for a secured network connection using SSL or TLS. It contains algorithms for key exchange, encryption, message authentication code (MAC) generation and pseudo-random number generation (PRF).

Naming of cipher suites follows the following structure:

[SSL/TLS] _ [Key Exchange] { _ [Authentication] } _ WITH_ [Encryption] _ [MAC]

For example: TLS_RSA_WITH_AES_128_CBC_SHA

Possible values for the individual components of a cipher suite are:

Key Exchange

• RSA
• RSA Export
• Diffie-Hellman Ephemeral Mode (DME)
• Elliptic Curve Diffie-Hellman (ECDH)
• Elliptic Curve Diffie-Hellman Ephemeral Mode (ECDHE)

Authentication

• DSS
• RSA
• ECDSA
• FIPS

Encryption

• RC4-40
• RC4-128
• DES-40 CBC
• DES CBC
• Triple DES (3DES) EDE CBC
• AES-128 CBC
• AES-256 CBC
• IDEA
• Camellia-128 CBC
• Camellia-256 CBC
• SEED CBC

Message Authentication

• MD5
• SHA

Just like the SSL version, the server chooses the Cipher Suite to be used in the SSL connection that is being established. Through modification of the Specification string in the httpd-ssl.conf configuration file of the Apache server, a malicious server can force a client into using an outdated and insecure Cipher Suite.

Therefore, the same thoughts on security apply as for SSL versions. The browser should not support any insecure Cipher Suites, but only a good selection of secure ones, so there is always at least one which is supported by a server.

Following is a list of Cipher Suites which are supported by the observed mobile browsers. Please note: This list only includes Cipher Suites which are activated by default. Those not listed are not supported by (or activated by default in) any of the observed mobile browsers.

Remarks:

• Cipher Suites marked as "Export" use DES with too small keys of mostly 56 Bit length and are therefore insecure. Same applies for any other Suite using DES.
• TLS_RSA_WITH_AES_128_CBC_SHA is specified a standard suite in RFC 5246. All 4 observed mobile browsers support it.
• Cipher Suites based on ECC (Elliptic Curve Cryptography) use much smaller key sizes compared to RSA based ones, while maintaining an equally high security. Due to the small key sizes and the accompanied "savings for power, memory, bandwidth, and computational cost" [18] they are especially suited for the comparatively weak processors of mobile devices.
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV protects against the TLS renegotiation attack [19], if a server is configured accordingly to support it. This suite can only be found in Firefox 3.6+ and Firefox Mobile, which is based on version 3.6.

When security sensitive data is transferred over the internet, certificates are used to secure the underlying connection. They cryptographically bind a public key to an identity using digital signatures, therefore providing not only the necessary data for securing a connection using SSL/TLS against eavesdropping or tampering, but also authentication of their owner.

The certificate owner always has to proof knowledge of the private key that belongs to the public key that is stated in the certificate. Since the public key has been signed by a trusted third party, a so-called certificate authority (CA), and bound to an identity, proof of knowledge of the respective private key equals authentication.

Authentication through a certificate is possible for both server and client. Since today the latter possibility is hardly made use of, only server certificates are observed here.

This chapter has a look at how valid and different types of invalid server certificates are handled by mobile browsers, shows possible attacks and compares, which data of a certificate can be viewed by the user in the four observed mobile browsers.

A certificate is accepted as valid, if it is included in the browser's list of trusted certificates, or is signed by one that is included. Browsers come with a number of certificate authority certificates, so-called root certificates, which are needed as possible roots for a "chain of trust". The principle behind a chain of trust is that entity A considers entity C to be trustworthy, if it is trusted by entity B, that in turn is considered trustworthy by entity A.

In desktop browsers, valid certificates underlying encrypted connections are awarded with well-visible, colored security batches next to the address bar, which evoke a visitor's trust. Therefore, certificates play an important role whereever sensitive data is sent between a client and server with absolute trust being desired, like for example on bank websites or web shops.

Some mobile browsers indicate secure connections in a similar fashion, others make it harder to check the current encryption status or certificate details.

• Firefox Mobile colors the area around the site favicon, which is displayed left of the address bar, according to the encryption status. Unencrypted sites are displayed black, encrypted sites are blue, sites which have an Extended Validation (EV) certificate are shown green. Clicking on the favicon brings up a panel showing basic certificate information, like the owner and issuer names, as well as a padlock to the left. However, there is no way to view more details about the certificate.
• MicroB shows a yellow bar near the upper screen end for about 4 seconds, which shows the verified URL and certificate owner. The yellow bar is not used exclusively for certificate information, but for numerous other notifications as well, like the saving of images. After it has been faded out, there are no other visual indicators for an encrypted connection. Site encryption and a few certificate details can be viewed by clicking on the site title, and then on "details".
• S60, when loading an encyrpted website with a valid certificate, displays a message that the website to be opened is secure. After the message has been checked, a little closed padlock is the only visible indicator for the connection encryption status. By bringing up the menu and clicking "Options", "Display options" and finally "Page info", the website address, encryption status and basic certificate information can be viewed.
• Mobile Safari shows a green colored padlock and the certificate owner's (company) name above the address bar. There is no option to view any certificate details.

While S60 and MicroB fail to offer the user enough insight in the current connection's encryption and the underlying certificate in an easily accessible and not so easily overlooked and attackable manner, Firefox Mobile and Mobile Safari do a better job in presention encryption status information. Out of these two, Firefox Mobile is certainly doing it the better way by offering a very well visible, color-coded button that brings up a panel with more information. Unfortunately it is lacking the possibility to view additional certificate details from there.

Independent from how well the necessary information is presented to the user, there is always the danger of visual spoofing attacks against mobile browsers, in contrary to desktop browsers. These allow SSL indicators to be faked, as described in chapter 6, making mobile browsers particularly vulnerable to fishing or similar types of attacks. More attacks on certificates will be discussed later in this chapter.

Based on the above observations, several guidelines for well-designed handling of encrypted connections and certificates can be phrased. This actually closely resembles Firefox Mobile's solution, with addition of a possibility to view further certificate details.

• The user should be presented with a well visible textual or optical indicator that shows the current connection status through distinct symbology or color codes.
• The user should be able to quickly check at least the most important information about the encrypted connection. These include the certified URL as well as the certificate owner and issuer.
• A quickly accessible link to a fully detailed certificate view is desired.

If verification of a certificate fails, if it has not been signed by a trusted CA, or if errors occur for any other reason, a certificate is considered invalid. The usual behaviour of browsers when being confronted with an invalid certificate is to present the user with a warning screen, that can not be circumvented. Such a screen usually shows general information regarding certificates, reasons why the current can not be accepted and gives a user the options to view the certificate, create an exception for it or leave the website. If an exception was made (i.e. the certificate has been imported into the browser's list of trusted certificates), warnings will no longer appear on future visits.

Certificates have both an issue and an expiry date. If the current time (according to the user's system clock) lies outside of the timeframe spanned by those two dates, a certificate is considered "expired" and therefore invalid.

This is less an indication for a fraud than an invalid certificate, since it means that the server at least had a valid certificate and most likely it has just not been renewed yet. Therefore, (desktop) Firefox as an example shows a less intrusive warning screen that offers a direct link for adding an exception, while invalid certificate warnings explicitely talk about risks in accepting the certificate and require the user to do multiple clicks in order to add an exception.

If a certificate is signed by its owner instead of a certificate authority, it is considered invalid, because, due to a missing trusted root, no chain of trust can be build.

This is even less an indication for a fraud than an invalid certificate or expired certificate. On one hand, a certificate is a requirement for a server to offer SSL/TLS encrypted communication, but on the other hand, such a certificate has to be bought from a certificate authority and might be connected to fees. Therefore, there are certain cases in which self-signing a certificate makes sense. One example is the mail system of the Ruhr-University Bochum⁵, which uses a self-signed certificate, which is sufficient, since there is no reason for students to not trust the university and not accept the certificate.

Taking the example of Firefox again, warning screens for self-signed certificates are of the same type as expired certificates, which are less intrusive than "regular" invalid certificate warning screens.

Mobile browsers handle invalid certificates in many ways similar to desktop browsers.

• Firefox Mobile acts the same way as the desktop version of Firefox, which was previously described. This is not surprising, since Firefox Mobile is based on the desktop version of Firefox.
• MicroB acts the same way as the desktop version of Firefox, which was previously described. This is not surprising, since MircoB is based on the desktop version of Firefox.
• S60 warns about invalid certificates by popping up a a non-circumventable warning screen that shows the reason for the certificate's invalidity. A user can either leave or click on "options". From there, it is possibile to view certificate details or add an either durable or temporary exception, which has to be permitted by yet another click. Self-signed and expired certificates are handled the same way, with one exception; it is not possible to add a durable exeption for expired certificates.
• Upon receiving an invalid certificate, Mobile Safari shows a full screen warning that can not be circumvented. It tells the user that the server identity could not be verified and offers the options to leave the site, view details or continue. The "details" screen shows the reason for not accepting the certificate and offers to view full details about it. Certificates can not be imported (i.e. exeptions can not be made) and there is no functional distinction between self-signed, expired or otherwise invalid certificates.

When presented with invalid certificates, all observed mobile browsers act as one would expect, although some lack the distinction between the different types like self-signed, expired or otherwise invalid certificates to reflect the different levels of possible threats they imply.

Extended Validation (EV) certificates are certificates that are bound to a strict process of verifying the identity of an issuer by a certificate autority (CA) than "regular" certificates [20]. They should therefore offer a higher level of trust and security.

For the user, "standard" and extended validation certificates should be easily distinguishable in some way. In Firefox Mobile, for example, the area behind the loaded site's favicon is colored black for an unsecured connection, blue for a SSL-secured one, and green for one that is backed by an EV certificate. Therefore a user can easily determine the level of security for the current connection. Not all mobile browsers offer such color coded guidance, though.

Due to the usually very strong encryption with which certificates are signed, it is not possible to fake valid certificates. However, as always there are ways around breaking the encryption algorithms, which allow making a browser accept invalid certificates.

Firefox based mobile browsers, like MicroB and of course Firefox Mobile, store certificates and exceptions in not sufficiently secured files in the user's profile folder. These are cert8.db for the list of trusted certificates and cert_override.txt for temporary exceptions.

If an attacker gains access to the phone's file system, he can manipulate or replace these files to add exceptions for any site. Access can be either physical or through malware, which could be hidden in plugins.

In order for the manipulated files to have an effect, the browser has to be restarted. In case of MicroB, which is the native browser of the Nokia N900 and therefore always runs in the background, the operating system has to be rebooted by restarting the phone.

The result of this is that a site, for which the certificate or an exception was inserted, is treated as if the user added it by himself - no warning is displayed and the site is treated like it had a valid certificate.

The following table shows, which certificate details can be seen by the user from within the browser (Not from the certificate manager of the underlying OS, like the one in Maemo.)

The term "mixed content" is used to describe both secure, SSL encrypted content through https:// and insecure content through http:// being contained on a website at the same time. If this is the case, a browser has to warn the user accordingly or block insecure content if necessary. This chapter describes and compares how the observed mobile browsers handle mixed content.

It is now observed, how mobile browsers react to an encrypted website that is being loaded through https://, but contains unsecured elements. Those could for example be images loaded over http://. The browser's ideal behaviour when receiving mixed content would be that the user is prompted with a warning that says that parts of the document are insecure, explains involved security risks when loading those and lets him choose to accept or decline loading them nonetheless. When the user chooses to accept loading insecure elements, it should be made clearly visible to the user that he is no longer communicating through a secured channel. If he declines, said elements should stay blocked and the connection remaining secure, which would be reflected in the browser GUI's SSL indicators.

It is now described how the observed mobile browsers react to this test case.

• S60 reacts correctly and just as expected. When loading a secured website, a padlock icon appears on the address bar. As soon as the browser notices unsecured content, it pops up a warning that tells the user that the website contains insecure objects and promts the user to accept or decline loading those. The padlock disappears and the insecure content is laoded if the user accepts, the padlock stays and the insecure content is not loaded if he declines.
• MicroB on the contrary does not warn at all about mixed content. The reason for this is the security.warn_viewing_mixed setting, that is set to false. As previously described, MicroB's only indication of a secured connection to the user is a yellow bar that provides very basic certificate information. It is displayed right after the SSL handshake and is faded out after about 4 seconds. So, if unsecured content is loaded after that, there are neither warnings, nor any way for the user to detect the presence of unsecured content other than navigating to the browser's "page details" view. Much worse, he is even made to believe that the connection is secure due to the initial appearance of the yellow certificate bar, so it is very unlikely that he will check the current connection security status.
• Firefox Mobile correctly handles mixed content. The browser warns the user accordingly and demands him to explicitly permit loading of insecure elements. The indicator mechanisms for secured connections, as described in the previous chapter, work flashlessly and correctly reflect the current connection status.
• Mobile Safari does not warn on receiving mixed content and displays all elements, secured and unsecured without any notice to the user. Only from the combination of the https:// shown in the address bar and the missing green padlock item and certificate owner name the observing user is able to reason the presence of mixed content.

As a second scenario, transitions from secured to unsecured connections are observed. When a user leaves a secure connection through a link or by sending data from a secured connection to an unsecured destination, he should be warned about that to make absolutely sure he is aware that he will no longer be communicating over a secure channel. Additionally, it gives him the opportunity to disallow the process.

It is now described how the observed mobile browsers react to this test case.

• S60 once again reacts correctly. It pops up a notice that the secure website is being left and prompts the user to either continue or not.
• MicroB spits a warning when data is about to be send to an unsecured goal out of a secured connection. But when following links within the same domain, the browser's SSL indicator bar is not displayed again, therefore making it hard for the user to detect leaving of a secured connection, since the connection protocol shown in the address bar is the only visible indication.
• Firefox Mobile correctly handles this case as well. The user is warned and the indicators are updated according to his decision.
• Mobile Safari does not display warnings in this case either, making it prone to all kinds of MITM ("Man in the middle") attacks in which data can be intercepted that the user sent thinking that he was communicating over a secure channel.

Although correctly detecting mixed contents under "normal" circumstances, some mobile browsers can easily be tricked by embedding insecure content with the use of iframes. The HTML iframe tag defines an inline frame which contains another HTML document. Both MicroB's and S60's mixed content detection mechanism can be tricked that way (no test data is available for Mobile Safari and Firefox Mobile.) Oliver Domke's observations of the S60 browser, which otherwise handles mixed content correctly, showed the following serious bugs:

• When loading a website over http in an iframe on a secured website that is being loaded over https://, the browser UI still shows the padlock which indicates the user that the website is supposedly secure and does not contain insecure elements. Only the browser's "page info" view lists the connection as "normal", which actually means "unsecured". It is therefore nearly impossible for the user to find out that the iframe content is not secure.
• If data is sent to an insecure location out of an iframe, it remains undetected by the browser and the user is not warned.
• Through this security hole, intercepting data sent by the user is easily possible.

The above observations show that not enough effort has been put into dealing with mixed content by the developers of most mobile browsers.

S60 does a good job in detecting mixed content and giving feedback to the user. The possibility to easily circumvent the detection by exploiting the described iframe bug renders the browser's protection practically useless, though. This also applies to MicroB, which is also prone to the iframe bug, but in addition fails to warn on mixed content anyway. Mobile Safari also fails to give the user sufficient feedback about the presence of mixed content. Only Firefox Mobile shows model behaviour when being confronted with mixed content and presents the user with appropriate warnings and indications.

The following chart sums up the observations made in this chapter.

The observations described in this thesis have shown that mobile browsers are still far behind desktop browsers when it comes to security of their users' data.

In particular, it is various comfort features of mobile browser which faciliate certain attacks or even make them possible in the first place. In chapter 6 it was shown that visual spoofing attacks are made possible because of the fullscreen modes of mobile browsers, which hide GUI elements in order to show content fullscreen and use as much as possible of the small screens. This allows attackers for example to display a fake address bar that can make the user believe that he is communicating over a secured channel while is actually not, or even simulate browser or phone menus. Only two of the four observed browsers show an icon that brings back up the GUI when it is not visible, and helps users to detect visual spoofing attacks.

When it comes to privacy, it has been shown that all observed mobile browsers only offer limited control about his personal data to the user, compared to desktop browsers. All browsers store passwords, visited sites and cookies and maintain a cache. The user has the possibility to disallow (some of) these mechanisms, but all are active in the default settings of all observed mobile browsers. This is another example of functionality that is meant to enhance usage comfort having a bad impact on security.

Mobile browsers also fall short regarding mixed content. Besides Firefox Mobile, all other examined browsers fail to give sufficient feedback to the user when loading mixed content or detecting it in the first place. Two of the four browsers can easily be tricked and do not warn on mixed content if it is loaded inside an iframe.

Of course there is a fine line between offering a browser that performs well on the limited resources mobile devices can offer and a feature-bloated monster application. A fine line between offering the user the necessary options to have adequate control over security of his data and making him not want to touch the browser options at all by simply offering too many. But with the market for mobile browsers expanding quickly, as shown in the introduction to this thesis, so does the number of possible threats. On the other hand, mobile devices are also becoming more and more powerful (with current models having 1 Ghz processors) making scaling down browsers to make them work with limited resources more and more unnecessary. It is therefore about time for mobile browser vendors to put more effort into making their products secure.

__________
1 http://www.zytrax.com/tech/web/browser_ids.htm#safari
2 An implementation of "array2json" can be found at: http://www.openjs.com/scripts/data/json_encode.php
3 http://safehistory.com/
4 http://technet.microsoft.com/de-de/library/cc783349%28WS.10%29.aspx
5 https://mail.ruhr-uni-bochum.de/mail
6 http://www.tipb.com/2009/03/31/iphone-30-mobile-safari-enhanced-security-certificate-visualization/

Illustration 10: [Screenshot] Deleting privacy data (S60, Nokia X6)

Illustration 11: [Screenshot] Privacy Options (S60, Nokia X6)

Illustration 12: [Screenshot] Deleting Privacy data (MicroB, Nokia N900)

Illustration 13: [Screenshot] Privacy Options (MicroB, Nokia N900)

Illustration 14: [Screenshot] Privacy Options (Mobile Safari, iPhone)

Illustration 15: [Screenshot] Certificate indicator (MicroB, Nokia N900)

Illustration 16: [Screenshot] SSL indicators and basic certificate view (Firefox Mobile 1.1, Nokia N900)

Illustration 17: [Screenshot] Page details view (MicroB, Nokia N900)

Illustration 18: [Screenshot] Certificate details view (MicroB, Nokia N900)

Illustration 19: [Screenshot] Certificate options (S60, Nokia X6)

Illustration 20: [Screenshot] Certificate details view (S60, Nokia X6)

[1] [Screenshot] Security settings of Firefox Mobile (Nokia N900)

[2] [Screenshot] Add-on Manager of Firefox Mobile 1.1 (Nokia N900)

[3] [Screenshot] Link styling on Google search results page (Firefox Mobile 1.1, Nokia N900)

[4] [Screenshot] "What the Internet knows about you" (wtikay.com) sample implementation of hybrid JavaScript/Pure CSS History Hack (Firefox Mobile 1.1, Nokia N900)

[5] Performance of the CSS History Hack using the JavaScript (left) and pure CSS (right) methods

[6] [Screenshot] Fake PayPal login page and respective fake GUI (Firefox Mobile 1.1, Nokia N900)

[7] [Screenshot] Fake PayPal login page and respective fake GUI, showing certificate information (Firefox Mobile 1.1, Nokia N900)

[8] [Screenshot] Arrow to bring back up browser GUI (S60, Nokia X6)

[9] Full TLS Handshake

[10] [Screenshot] Deleting privacy data (S60, Nokia X6)

[11] [Screenshot] Privacy Options (S60, Nokia X6)

[12] [Screenshot] Deleting Privacy data (MicroB, Nokia N900)

[13] [Screenshot] Privacy Options (MicroB, Nokia N900)

[14] [Screenshot] Privacy Options (Mobile Safari, iPhone)

[15] [Screenshot] Certificate indicator (MicroB, Nokia N900)

[16] [Screenshot] SSL indicators and basic certificate view (Firefox Mobile 1.1, Nokia N900)

[17] [Screenshot] Page details view (MicroB, Nokia N900)

[18] [Screenshot] Certificate details view (MicroB, Nokia N900)

[19] [Screenshot] Certificate options (S60, Nokia X6)

[20] [Screenshot] Certificate details view (S60, Nokia X6)

[1] CSS History Hack (JavaScript Method) Source Code (Part 1, CSS)

[2] CSS History Hack (JavaScript Method) Source Code (Part 2, JavaScript)

[3] CSS History Hack (CSS Method) Source Code

[1] Michal Zalewski, Browser Security Handbook (2008, 2009), http://code.google.com/p/browsersec/

[2] Christian Radke, (Mobile) Browser Market Share (February 2011)

[3] differencebetween.net, Difference Between Add-on and Plug-in (2010), http://www.differencebetween.net/technology/difference-between-add-on-and-plug-in/

[4] Adobe Security Bulletin, Security Advisory for Flash Player, Adobe Reader and Acrobat (June 2010), http://www.adobe.com/support/security/advisories/apsa10-01.html

[5] Aza Raskin, Tabnabbing: A New Type of Phishing Attack (May 2010), http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/

[6] Eitan Adler, Tabnabbing without JavaScript (May 2010), http://blog.eitanadler.com/2010/05/tabnabbing-without-javascript.html

[7] Dan Mills, Account Manager coming to Firefox (April 2010), http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/

[8] David Baron, Bug 147777 - :visited support allows queries into global history (May 2002), https://bugzilla.mozilla.org/show_bug.cgi?id=147777

[9] Artur Janc, Lukasz Olejnik, Feasibility and Real-World Implications of Web Browser History Detection (May 2010), http://w2spconf.com/2010/papers/p26.pdf

[10] Alan O. Freier, The SSL Protocol Version 3.0 (November 1996), http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

[11] B. Carpenter, RFC 1958 - Architectural Principles of the Internet (June 1996), http://tools.ietf.org/html/rfc1958

[12] T. Dierks, C. Allen, RFC 2246 - The TLS Protocol Version 1.0 (January 1999), http://tools.ietf.org/html/rfc2246

[13] T. Dierks, E. Rescorla, RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 (April 2006), http://tools.ietf.org/html/rfc4346

[14] T. Dierks, E. Rescorla, RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008), http://tools.ietf.org/html/rfc5246#page-5

[15] Mozilla, Gecko FAQ, https://developer.mozilla.org/en/gecko_faq

[16] symlab.org, Symbian OS Communications Programming/6. IP and Related Technologies (July 2009), http://www.symlab.org/wiki/index.php/Symbian_OS_Communications_Programming/6._IP_and_Related_Technologies

[17] Apple, Safari Web Content Guide (2010), http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html#//apple_ref/doc/uid/TP40006482-SW1

[18] Network Working Group, RFC 4492 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (May 2006), http://www.faqs.org/rfcs/rfc4492.html

[19] Internet Engineering Task Force (IETF), RFC 5746 - Transport Layer Security (TLS) Renegotiation Indication Extension (February 2010), http://tools.ietf.org/html/rfc5746

[20] CA/Browser Forum, Guidelines For The Issuance And Management Of Extended Validation Certificates (October 2009), http://www.cabforum.org/Guidelines_v1_2.pdf