netsekure rng

I have been using separate browsers for a while now to isolate generic web browsing from “high value” browsing, such as banking or administration of this blog. The reason I’ve been doing this is that a compromise during generic web browsing is going to be isolated to the browser being used and the “high value” browser will remain secure (barring compromise of the underlying OS).

Recently I’ve decided to give the experimental Chrome feature - ”isolated apps” – a try, especially since I’ve recently started working on Chrome and will likely contribute to taking this feature to completion. Chrome already does have a multi-process model in which it uses different renderer processes, which if compromised, should limit the damage that can be done to the overall browser. One of the limitations that exists is that renderer processes have access to all of the cookies and other storage mechanisms in the browser (from here on I will only use cookies, though I mean to include other storage types as well). If an attacker can use a bug in WebKit to get code execution in the renderer process, then this limitation allows requesting your highly sensitive cookies and compromising those accounts. What “isolated apps” helps to solve is isolating storage for web applications from the generic web browsing storage, which helps solve the problem of a compromised renderer stealing all your cookies. In essence, it simulates running the web application in its own browser, without the need to branch out of your current browser. The aim of this blog post is not to describe how this will work, but how to take advantage of this feature. For the full details, read the paper by Charlie Reis and Adam Barth (among others), which is underlying the “isolated apps” work.

In the spirit of my “30 days with …” experiments, I created manifests for the financial sites I use and for my blog. I wanted to see if I will hit any obvious breaking cases or degraded user experience with those “high value” sites. A sample manifest file looks like this:

{
  "name": "netsekure blog",
  "version": "1",
  "app": {
    "urls": [ "*://netsekure.org/" ],
    "launch": {
      "web_url": "https://netsekure.org/wp-admin/"
    },
    "isolation": [ "storage" ]
  },
  "permissions": [ "experimental" ]
}

The way to read the file is as follows:

• The “urls” directive is an expression defining the extent encompassed by the web application.
• The “web_url” is the launch page for the web app, which provides a good known way to get to the application.
• The “isolation” directive is instructing Chrome to isolate the storage for this web app from the generic browser storage.

Once the manifest is authored, you can place it in any directory on your local machine, but ensure the directory has no other files. To actually take advantage of this, you need to do a couple of things:

• Enable experimental APIs either through chrome://flags or through the command line with –enable-experimental-extension-apis.
• Load the manifest file as an extension. Go to the Chrome Settings page for Extensions, enable “Developer Mode”, and click on “Load unpacked extension”, then navigate to the directory where the manifest file resides and load it.

Once you have gone through the above steps, when you open a new tab, it will have an icon of the isolated web application you have authored. You can use the icon to launch the web app, which will use the URL from the manifest and will run in a separate process with isolated storage.

Now that there is an isolated app installed in Chrome, how can one be assured that this indeed works? There are a couple of things I did to confirm. First, when a Chrome web app is opened, the Chrome Task Manager shows it with a different prefix. Generic web pages start with “Tab: ” followed by the title of the currently displayed page. The prefix for the apps is “App: “, which indicates that the browser treats this tab as a web application.

In addition to seeing my blog being treated differently, I wanted to be sure that cookies are not shared with the generic browser storage, so I made sure to delete all cookies for my own domain in the “Cookies and Other Data” settings panel. As expected, but still to my surprise, the site continued functioning, since deleting the cookies only affected the general browser storage and my isolated app cookies were not cleared. This intrigued me as to where those cookies are being stored. It turns out, since this is still just an experimental feature, there is no UI to show the storage for the isolated app yet. If you want to prove this to yourself, just like I wanted to, you have to use a tool to let you peek into a SQLite database, which stores those cookies in a file very cleverly named – Cookies. The Cookies db and the cache are located in the directory for your current profile in a subdirectory “Isolated Apps” followed by the unique ID of the app, as generated by Chrome. You can find the ID on the Extensions page, if you expand to see the details for the web app you’ve “installed”. In my case on Windows, the full directory is “%localappdata%\Google\Chrome\User Data\Default\Isolated Apps\dgipdfobpcceghbjkflhepelgjkkflae“. Here is an example of the cookies I had when I went and logged into my blog:

As you can see, there are only two cookies, which were set by WordPress and no other cookies are present.

Now, after using isolated apps for 30 days, I haven’t found anything that was broken by this type of isolation. The sites I’ve included in my testing, besides my blog, are bankofamerica.com, americanexpress.com, and fidelity.com*. The goal now is get this to more usable state, where you don’t need to be a Chrome expert to use it ;).

* Can’t wait for all the phishing emails now to start arriving ;)

I was recently listening to Chris Palmer talking about SSL on the PaulDotCom podcast and one thing caught my attention – the discussion on IE behavior with trusted roots certificates. It was discussed that IE is violating the “No-Write-Up” policy of the integrity level (IL) mechanism in Windows. While the end effect looks like it, the inner workings of how this is accomplished is more complicated and the behavior is not restricted to IE.

Let’s start with some preliminary background information:

• Certificates are validated through a process of building a chain up to a trust anchor, the underlying of which is constructing a graph of nodes (certificates) and edges (issuance relationships) and then the graph is traversed to find all possible complete chains (in most cases just one). The smaller the graph is, the quicker it is to find a complete chain. Once the chain is complete, the certificate at the root of the chain is checked for trust. If the chain ends in a certificate present in the list of trusted root certificates and all other verifications pass, the certificate validation is successful.
• Microsoft has a specific program called “Microsoft Root Certificate Program”, which is how certificate authorities (CAs) submit their root certificates for inclusion in Windows. The end result of this program is a *fixed* list of root certificates that Windows considers trusted. The entire list is available on TechNet and is updated whenever there are any changes. This list (or the equivalent of it at the time) was present in full in the root certificate store in Windows XP and earlier, but starting with Vista, this default list in the root certificate store is much smaller in order to increase performance while validating certificates. If a chain ends up in root certificate which is part of the Root Program but is not present in the list of trusted roots currently on the machine, Windows downloads the appropriate root certificate directly from Windows Update. The full process for all versions of the OS is described in a KB article. I’m not going to rehash the explanation of how it works, but the key point is that only those certificates accepted through the root program will be downloaded from Windows Update.

The IE low integrity processes are not instructing the broker to do anything, it all happens under the hood in the crypto APIs. Now, here is why the IE behavior is observed. You go to a web site, which certificate is issued by a CA not yet in your trusted root list. Because IE uses the standard cryptography API that Windows provides, when certificate validation is performed, Windows itself (not IE, nor its broker process) goes and fetches the root certificate from Windows Update *if* that certificate is part of the Root Program. The same behavior will be seen for any program that is using the same API to do certificate validation. Chrome as far as I know uses the Windows crypto APIs to do certificate validation and relies on the trusted roots list from Windows, so if you browse with Chrome, you will see the exact same thing happen (though I haven’t verified it personally).

Some people have asked me how they can prevent Windows from going to Windows Update in such cases. This can be achieved by disabling automatic root update through policy as described on TechNet. It should be noted that one should exercise caution in doing so, because disabling root update means that Windows will no longer manage certificate trust for you. You will have to manage the set of trusted root certificates on your own. To that end, import the full list of CAs part of the Root Program such that those are available in the list of trusted roots. Microsoft provides a small program – rootsupd.exe, as part of KB931125 which accomplishes this task. With this approach, you have control over trust management, but you need to keep the list updated whenever the set of roots in the root program changes. Microsoft has a wiki page which includes the information about new certificates that are part of an update. This page has RSS feed available which you can subscribe to so that you are notified of new updates, which makes keeping track of the updates an easy job.

I hope this helps explain how this all works and clarify that there is no real violation of the No-Write-Up policy, even though it might seem like it from high level.

Today marks the 30th day since I removed all the root certificates for trusted certificate authorities. It was an interesting one month and I’ve learned a bunch. The main takeaway from this experiment is that I don’t need 3 digit number of trusted CAs in my browser. Again, this is person specific and US centric, but the total count as of today is 10! The list of subject names and signatures follows for the ones interested in the exact list.

CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
7e784a101c8265cc2de1f16d47b440cad90a1945

OU = VeriSign Trust Network, OU = “(c) 1998 VeriSign, Inc. – For authorized use only”, OU = Class 3 Public Primary Certification Authority – G2, O = “VeriSign, Inc.”, C = US
85371ca6e550143dce2803471bde3a09e8f8770f

OU=Class 3 Public Primary Certification Authority, O=VeriSign, Inc., C=US
742c3192e607e424eb4549542be1bbc53e6174e2

OU=Equifax Secure Certificate Authority, O=Equifax, C=US
d23209ad23d314232174e40d7f9d62139786633a

CN=GTE CyberTrust Global Root, OU=”GTE CyberTrust Solutions, Inc.”, O=GTE Corporation, C=US
97817950d81c9670cc34d809cf794431367ef474

CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US
99a69be61afe886b4d2b82007cb854fc317e1539

CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
02faf3e291435468607857694df5e45b68851868

E=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA
627f8d7827656399d27d7f9044c9feb3f33efa9a

OU=Go Daddy Class 2 Certification Authority, O=”The Go Daddy Group, Inc.”, C=US
2796bae63f1801e277261ba0d77770028f20eee4

CN = GlobalSign Root CA, OU = Root CA, O = GlobalSign nv-sa, C = BE
b1bc968bd4f49d622aa89a81f2150152a41d829c

The last one I’ve included for completeness, since I don’t really need it, but I had to enable it to access openssl.org over https. It is currently not trusted.

While this is a good list of certs to enable for security geeks like myself, I’m not quite sure how feasible this is today for the average user, so I wouldn’t recommend doing this to your parents’ computer. Even for me it was hard to realize that application failures (such as twhirl completely stopping to work) are due to a root certificate no longer being trusted and SSL connections failing. I also had to look at the wire traffic on a few occasions where the UI would never expose the “I want to see which certificate is failing” option.

One needs to be very careful which certs are disabled. Since it is hard to troubleshoot failures that result from disabling trusted roots, reading up and getting familiar with how certificates work is a great idea. Firefox has its own certificate storage, completely separate from the OS, so messing with it is not as big of an issue, as any errors are isolated to Mozilla applications. Here are some resources for Windows (which affects IE and Chrome):

• There is a list of mandatory certificates that Windows needs to operate, which is listed here.
• There is a great overview of how the trusted roots certificates work on Windows and explains why people see things “change” under the hood.
• Also, in newer versions there seem to be a lot more control on how certificates are validated and what roots are trusted.
• The list of CAs that Windows trusts.

I hope this information is helpful to people. Feel free to ping me with questions you might have related to this small project.

As part of my testing of how many trusted root certificates I need for my day-to-day activities, I needed to ensure I don’t trust any certificate authorities. There is a great post by Nelson Bolyard to one of the security mailing lists of Mozilla, which explains why one should not delete CA certificates, but rather disable them. The main take away is that there is a big difference between the statements “I don’t know you” (if you remove the certificate) and “I know you and I don’t trust you” (disabling the certificate). Some browsers also handle these errors differently.

The different browsers store certificates differently. IE, Chrome, and I believe Safari as well (haven’t tested it) on Windows use the OS built-in certificate infrastructure, while Firefox uses its own certificate storage. As such, here are the steps you need to take for the two different cases:

IE, Chrome (Safari?)

You need to run the certmgr.msc utility (either through Start->Run/Search or from a command prompt). This will launch the UI used to manage the certificate stores in Windows for the current user.

CertMgr Certificate Stores

The “Third-Party Root Certification Authorities” stores all the trusted 3rd party CAs. You will find either a fairly small set of those if Windows hasn’t downloaded the full list, or quite a bit of them after the full list has arrived. To disable the root certificates, select the ones you want and drag them to the “Untrusted Certificates” store and drop them under the “Certificates” subfolder. This instructs the certificate infrastructure in Windows to not trust these certificates. The result is that even though you have the certificates in other stores, the operations will fail. The “Untrusted Certificates” store trumps all others, so you don’t have to worry about forgetting a certificate somewhere else.

Keep in mind that doing this in Windows will affect all programs that use SSL/TLS and certificates. I’ve broken my twitter client for example by removing all CAs from the trusted list : ).

Firefox

You will need to click on Tools->Options, select the Advanced category, select the Encryption, click View Certificates, and click on the Authorities tab. This will open up a window with all the trusted certificate authorities. For each of those, once you select it, you can click on the “Edit” button and you will see a window that looks like this:

Firefox Trusted CA

This CA is trusted for all 3 types of identification. To disable the certificate, just uncheck all the check boxes and click Ok:

Firefox Disabled CA

The result is that this certificate is no longer trusted to vouch for the identity of anything. You need to repeat the process for all the certificates you want to disable and I don’t know of an easy way to automate this. For the certificates listed as “Builtin Object Token”, Marsh Ray has tried deleting them and claims that this results in disabling them (since they are built-in and cannot be deleted) after restarting Firefox.

After you have disabled the CA certificates, you can expect SSL/TLS connections to fail if the certificate is issued by a disabled CA.
Have fun browsing with minimized attack surface : )