Abstract:
A method of creating and using a virtual private network (VPN) client encrypts network communications to server/gateways using strong algorithms to ensure data integrity and privacy during transport. Transport uses standard HTTP packets. Encryption and integrity are provided by using Secure Socket Layer (SSL, sometimes referred to as TLS). This invention is compatible and portable to different computer operating systems and mobile devices, and is also lightweight, allowing for ‘clientless’ installation and removal or small-footprint (thin) client software installations. The invention can also secure mobile user communication links over public wireless hotspots or wired Internet links.

Description:
[0001]    This application claims priority from U.S. Provisional Application Ser. No. 60/913,712, filed in the United States Patent and Trademark Office Apr. 24, 2007, and entitled Method to create an OSI network layer 3 virtual private network (VPN) using an HTTP/S tunnel. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    The present invention pertains to computers communicating over large communication networks, such as the internet or wide area networks (WAN). The invention further relates to communication between computers over a large communication network where a client computer is accessing the network via connections provided by unknown parties or public services, where data transfer security and privacy for the client end-user is a concern. 
         [0003]    Virtual Private Network (VPN) is a term to describe various methods used to encrypt, compartmentalize and privatize data by trusted computer systems when transmitted over insecure networks. VPNs create what is called a ‘tunnel’ through the insecure network connecting two or more of the trusted computer systems. Intermediaries in the network are prevented from seeing or tampering with data transmitted through the VPN tunnel, thus protecting the security and integrity of the data transmitted through the VPN. Tunneled and encrypted communication by VPN has traditionally been provided by companies to their employees for company use. The need for encrypting traffic by the general public has not been a focus of the VPN software, service and equipment providers. The creation and availability of numerous wireless hotspots that provide access to the Internet to the general public from public locations has changed the scope of how VPN should be delivered. 
         [0004]    The proliferation of wireless hot spots, whether coffee shops giving wireless internet access to their customers or cities that prove such access to their residents, has dramatically increased the number of places from which people can access a main network. Now, the general public also has a need to ensure that their communications are encrypted, but instead of the ‘typical’ VPN deployment of encrypting traffic to and between a company&#39;s network(s), the general public would desire to have its traffic encrypted during transit to the Internet. The reason is that publicly provided Internet access links (either wireless or wired) can be monitored by the providers of those links without the knowledge of the end-user who is accessing the service. URLs, email, instant messaging, unencrypted authentication credentials and any other easily detectable traffic generated by the end-user can be monitored, logged, and archived by the local hotspot provider very easily. The end-user generated traffic, especially wireless, is also easily open to interception from a peer host within wireless range or that is accessing the same provider hotspot. 
       SUMMARY OF THE INVENTION 
       [0005]    This invention addresses the general public&#39;s need for encrypted communication by establishing a secure connection from a client system to a server using HTTP/S POST and HTTP/S GET commands to establish a secure tunnel. 
         [0006]    Because of this invention&#39;s efficient design and extremely low software footprint, there is an embodiment of this invention that requires no manual client software installation or removal on the end-user system before or after use. The ‘clientless’ usage functionality of this invention removes a major usability issue in delivery, since the typical end-user or administrator does not want the complexity of installing and configuring client-side VPN software in order to create tunnels to the server/gateway. Client software removal can proceed automatically as well after the end-user has finished using the VPN. 
         [0007]    The standard client application software installation, if preferred by the end-user or administrator, is also very small (thin-client) and transparent in use. The thin-client provides very fast tunnel connect and disconnect functionality for the end-user who wishes to quickly ‘scramble’ their network communications when privacy or security is needed over an insecure network topology. 
         [0008]    The basic architecture designed into this invention allows porting to new devices and operating systems very easily and quickly. Thus, versions of this invention can be quickly deployed for network capable mobile phones, portable data assistants (PDAs) and similar mobile devices. Supporting the client architecture on these devices is simplified by being computer operating system (OS) agnostic and relying on standard OS HTTP library implementations. In short, if the mobile device supports the web, it can use this invention. 
         [0009]    An additional benefit of this invention over other types of VPNs, is that clients using this invention to encrypt their traffic are more likely to work seamlessly over the insecure network. Other types of VPNs use network ports or methods that may be either blocked or incompatible with the network topology that a client system is connected to. An example would be networks using NAT, which would be typical of wireless hotspots, but incompatible with certain VPNs. Another example would be VPN technologies using GRE protocols, which would typically be blocked on third party or public networks. This invention uses a commonly used protocol (HTTPS) and is fully compatible with NATted networks, and so is more likely to be used transparently to secure data where other VPN methods would fail. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0010]      FIG. 1  is a diagram of the overview client/server transmit and receive flow chart. 
           [0011]      FIG. 2  is a diagram of the client to server packet transmission sequence breakdown. 
           [0012]      FIG. 3  is a diagram of the server to client secure packet receive sequence breakdown. 
           [0013]      FIG. 4  is a diagram of a model secured internet packet that uses the invention. 
           [0014]      FIG. 5  is a detailed diagram of the HTTP/S VPN architecture implemented in user/kernel space. 
           [0015]      FIG. 6  is a diagram depicting the server as an intermediary between the client system and a desired web site. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0016]      FIG. 1  depicts an overview of this invention and how it is used to secure IP data packets over an insecure network creating a VPN between the client and server. A client system  101  running the client application  103  establishes a secure data transmit/receive tunnel to a server  102  over an insecure network topology  109 . 
         [0017]    In the embodiment depicted in  FIG. 1 , the client application  103  contains an integrated virtual network adapter driver  105 , and is capable of transmitting and receiving data packets through the client system&#39;s physical network adapter  113 . The virtual network adapter  105  obtains its own network addressing (in the embodiment depicted in  FIG. 5  this is done via DHCP). This virtual network adapter is then used by the client system&#39;s operating system (OS)  114  to redirect transmit and receive data packets that normally would be sent or received directly to or from the physical network adapter  113 . In effect, the installed virtual network adapter  105  now acts as the intermediary between the client computer OS  114  and the client computer physical network adapter  113 . This allows selection and interception of IP packets, allowing them to be encrypted for transport over the VPN. With the network IP packets intercepted, the client application  103  can act upon the packets to secure them through encryption or otherwise. 
         [0018]    The server  102  in  FIG. 1  contains invention components that include a web server  104 , an input/output module, such as the GCI module(s)  106 , a credential authentication system, such as the RADIUS client, and a queue  111  for queuing packets generated in the server OS  115  and destined for the client system  101 . 
         [0019]    In accordance with the invention, communications from the client system  101  to the server  102  form a secure channel. Requested data is encapsulated the in IP packets  201  inside of HTTP/S packets  202 . Making a request to the web server  104  for each incoming encapsulated packet  203  would be bandwidth intensive and inefficient. Instead, the invention forms an initial connection to the web server  104  to control how incoming (receive) packets to the client system  101  are handled. In  FIG. 3 , the client application  103  generates an initial connection by sending an HTTP/S-GET  108  to the web server  104  over SSL (HTTP/S) to a target URL (example: https://targetserver.com/clientreceive.cgi) over the client system&#39;s  101  physical network adapter  113 . This target URL addresses a server-side component. In the embodiment presented in  FIG. 1 , the addressed server-side component is the Transmit URL  106   b  in the CGI module  106  hosted by the web server  104 . Note that the Transmit URL  106   b  and the Receive URL  106   a  may be different URLs or the same URL. 
         [0020]    The server  102  will then establish a secure channel, the Server Push Stream  112 . The HTTP/S-GET packet  108  generated by the client system  101  contains authentication credentials or other tunnel settings specific to this client system  101 . Various authentication methods currently known in the art can be used with this invention, such as methods described inside the HTTP standard itself for use with HTTP connections to web servers to other authentication methods unrelated to HTTP. The embodiment in  FIG. 1  shows credentials being passed inside the HTTP/S-GET request  108  and the client system  101  is authenticated when the invention CGI module  106  passes those credentials to a standard RADIUS client  110  on the server  102 . Once the client system  101  has been authenticated, CGI module  106  on the web server  104  will then start a persistent connection, a web server “push” method, to establish the Server Push stream  112  to the client system  101 . This connection is used to send any encapsulated IP packets (See  FIG. 3 ) destined to the client system  101 . The Server Push stream  112  can be any web server ‘push’ connection established using special HTTP connection types such as Content-Type multipart/x-mixed-replace; or can be contained as features in newer web based languages such as Asynchronous JavaScript™ and XML (Ajax). 
         [0021]    Communication from client system  101  to server  102  takes place as follows: Transmit IP data packets  201 , destined from the client system  101  to the server  102  over the invention&#39;s VPN, are placed inside an HTTP packet  202  as POST data by the invention client application  103 . A call is then made to HTTP libraries  116  on the computer system to create a connection to the web server  104  component of the server  102 . The packet containing the IP packet as POST data is then secured using SSL and then sent to the web server  104  as an HTTP/S POST transmission  107  over the client system&#39;s  101  physical network adapter  113 . The target of the HTTP/S POST, the web server&#39;s  104  input/output module, can vary based on what is best suited to the type of application the invention is applied to. The embodiment in  FIG. 1  uses common gateway interface (CGI) modules. The target in this embodiment is the Receive URL  106   a  in the CGI module  106  hosted by the web server  104  software (example: https://targetserver.com/clientsend.cgi). This CGI module  106  is discussed in greater detail in the server section below. This client generated HTTP/S-POST packet can also contain authentication credentials or other tunnel settings specific to this client system  101 . 
         [0022]    Communications packets arrive at the server  102  from the client systems as an HTTP/S-POST using SSL  107 . The web server  104  on the server  102  accepts these packets over its network listening port. Once at the web server  104 , the SSL packet  203 , is validated, decrypted and the resulting HTTP/S-POST (see  FIG. 2 ) containing the original client system IP packet  201  is passed into the input/output module where the original packet and any authentication credentials sent by the client system  101  (see  FIG. 4 ) can be extracted. In the embodiment shown in  FIG. 1 , POST data is passed into the Receive URL  106   a  in the CGI Module  106 . The CGI Module  106  then processes the POST data to extract the original IP packet. The original IP packet is injected into the server&#39;s OS networking stack  115  for routing to its intended destination, which can either be to networks local or external to the server, depending upon the IP addressing of the original packet generated in the client system&#39;s OS  114  prior to manipulation by the client application  103 . The CGI module  106  can also be implemented to perform special-case processing to handle network broadcast or DHCP communications (see  FIG. 5 ). 
         [0023]    Communication from the server  102  to the client system  101  takes place as follows: The Server Push stream  112  is started by the server&#39;s CGI module  106  through the web server  104  to the client application  103  on the client system  101 . Data packets are then streamed using SSL to the client system  101  over the Server Push stream  112  without additional HTTP/S-GET requests. Once the Server Push stream  112  is established, the input/output module listens for IP packets from the queue  111 . Using server routing rules, the queue  111  separates out the traffic arriving on the server  102  and destined to client system(s)  101  connected to the VPN. The server&#39;s queue  111  performs a similar task to the client application&#39;s virtual network adapter on the client system  101 : it intercepts IP packets destined for the VPN client system(s) and ignores other network traffic, such as network management traffic, monitoring traffic or other traffic unrelated to the VPN communications. The queue  111  gathers IP packets addressed to VPN client system(s), and forwards them to the input/output module (the CGI Module  106  in the embodiment shown in  FIG. 1 ). Once the IP packets are forwarded from the queue  111  to the CGI Module  106 , they are then sent securely to the client system  101  over the previously established the Server Push stream  112 . 
         [0024]      FIG. 5  shows details of the invention components in relation to their respective computer system components. In  FIG. 5 , the user space (the top half of  FIG. 5 , the high level application processes) is separated from the kernel space (the bottom half of  FIG. 5 , the low-level OS processes), and the client system  101  (the left half of  FIG. 5 ) is separated from the server  102  (the right half of  FIG. 5 ). The client application&#39;s virtual network adapter  501  is shown in the kernel since this is considered a low-level driver used by the client system OS. 
         [0025]    The invention components in  FIG. 5  also include the client application&#39;s virtual network adapter, gttap.sys  501 ; the client application&#39;s system that creates a VPN, gtclient.exe  502 ; a CGI Module on the web server, gtcgi  503 ; the queue  111  on the server, gtqd  504 ; the persistent connection from gtcgi  503  to the Server Push stream  112  gtclient.exe  502 . 
         [0026]    The embodiment shown in  FIG. 5  represents a client system running the Windows OS and a server running the Linux OS and the Apache web server application. 
         [0027]      FIG. 6  illustrates one use of the invention in which the server  102  acts as an intermediary between the client system  101  and a desired web site  601 , and a secure client-server communication connection  602  is set up to protect a client who is accessing the internet through a wireless hotspot. 
         [0028]    The client application  103  is designed to be thin (taking up few of the client system&#39;s resources) and transparent to users. Other embodiments eliminate the need for a client application  103  by modifying the web server  104  or input/output module on the server  102  to simulate the functionality of the client application  103 .