The Benefits and Pitfalls of Using Sandboxing Techniques in SSL VPN, Part 1
By Dr. Matthias St. Pierre, Senior Developer at <a href="http://www.ncp-e.com/">NCP engineering</a><a href="http://vpnhaus.ncp-e.com/wp-content/uploads/2012/08/matthias1.png"><img class="alignright size-full wp-image-3175" title="matthias" src="http://vpn
When connecting to your company network with an SSL VPN, you are using your standard web browser to access an SSL-secured website, which the company provides. After logging in, typically, a graphical user interface appears in the browser that gives you limited access to company resources, like your business e-mails or other confidential documents.
Because modern browsers and applications cache all downloaded data for performance and convenience purposes, most of the sensitive information that you access via an SSL VPN is written on the computer’s file system where others could potentially access it. This happens -- not when you explicitly press ‘Download’ or ‘Save as’ -- but also, implicitly whenever you follow a link or view file contents. Even if you clear the browser cache when terminating the session, the deleted files can easily be recovered using standard tools. This can be problematic if the computer you are using is not owned by your company and not subject to minimal endpoint policies.
This is where sandboxing comes in. At NCP, one of our main goals when it comes to sandboxing is to protect confidential data by ensuring that all write operations to the file system are transparently redirected to a secure location, where the file contents are secured on-the-fly using AES encryption. A thin client program, which is downloaded at the beginning of the SSL VPN session and acts as a guardian process, helps to achieve this. The thin client injects a DLL into a newly created browser instance and all of its descendant processes, in order to monitor and modify the Windows file system API calls. All further browsing occurs in the sandboxed browser. Moreover, the thin client starts the new browser instance on a different Windows™ desktop, in order to isolate the sandboxed processes from the other processes running on the original Windows desktop.
This way, write access to files can either be prohibited or virtualized by transparently redirecting it to a shadow folder, depending on the location of the file and the policies given by the administrator. Registry access is sandboxed in a similar fashion. It’s important to note, the thin client program requires no installation and no administrative rights in order to operate.
Learn more about the side effects of taking this approach in part two.