SECURED SESSION SEQUENCING PROXY SYSTEM SUPPORTING MULTIPLE APPLICATIONS AND METHOD THEREFOR
BACKGROUND OF THE INVENTION
The present invention relates to network data communications, and more particularly to establishing one or more secure data communication sessions between applications executing on a public client system and one or more internal hosts in which the hosts and internal network are secured from unauthorized access.
The proliferation of users and services on global computer networks such as the Internet raises security concerns for both users and service providers . Users want the data they submit to providers and the data they receive from providers to be free from unauthorized interception and use. Similarly, service providers want their hosts and systems secured from unauthorized access and intrusion by "hackers". Service providers, especially those involved with financial services view their computing hardware and software as critical assets. These service providers rely on the trust of their customers who assume that no one will be able to access customer records or otherwise negatively impact the service .
Prior on-line services used dedicated dial-up facilities, and customized security software on the user's terminal and the host system to prevent
unauthorized access. In other words, users were forced to access the service provider's system by dialing a special telephone number. Transmitted data was secured by encryption, and incoming dial-up calls were only accepted from authorized users. Security software was also implemented on the provider's host system. This became very inefficient and cumbersome as users began to subscribe to multiple on-line services.
Global computer networks such as the Internet allow users to access many different hosts and services from their computers via a single access connection. While this has enhanced users' abilities to access information and conduct business, global networking has complicated service providers' security mechanisms. For example, a service provider must allow inbound (from the network to the service) access to their site for everybody. This results from the service providers' inability to be sure of the originating computer address, such as a TCP/IP (Transmission Control Protocol/Internet Protocol) address from which actual or prospective users will communicate. It is too inefficient and impractical to allow access on an address by address basis, especially since computer addresses can change every time a user connects to their network access provider. As a result, service providers must allow access for the entire network community, and
service providers are forced to use other methods to secure access to their hosts, and to secure the data contained on their hosts.
Security systems and methods have been developed which employ the use of special security software on both the user's terminal and the host system. These types of security systems use a public and private key pair challenge mechanism using data encryption and Digital Signatures for authentication. This provides a secure session, but every user must have a copy of this software in order to access the host . Service providers offering this type of access software must offer customers installation support and problem determination services, and must also update the special software as needed. This increases the complexity of the system and drives up the cost of providing the service.
Other encryption software, such as Secure Sockets Layer (SSL) handshake protocol is used for client and host authentication. SSL is application independent and negotiates encryption keys and allows the client-system to authenticate the host prior to allowing data communications. SSL is typically implemented in Internet web browser software. Thus, it facilitates secure data transmission between a user and a host. This allows a user to be sure that communication between their client
terminal and the host is free from unauthorized interception, but still does not protect the service provider's host from security attacks.
Service providers have attempted to secure their hosts by interposing firewalls and proxy servers between their hosts and the user community. Firewalls are typically programmed to restrict inbound access to a particular set of users, or to restrict access to a particular set of hosts or ports, i.e., services. In a system using a proxy server, the client system communicates with the proxy server which in turn communicates with the host. In this configuration, a user (client system) establishes a session with a proxy server and the proxy server establishes a session with the host .
As discussed above, restricting user access is not practical, and restricting services still leaves a security hole through which crafty hackers can enter. In other words, since a small opening must be maintained in the firewall to establish the inbound connection, it is still possible for unauthorized users to access the host.
Further security breaches are possible because firewalls typically allow direct session communications between the user's terminal and the host system. Direct session communication refers to a client system
addressing data packets such that the final destination address is indicated as the terminus host machine. This provides the user with the actual host address. It is desired to protect the host address in confidence such that users do not know what the host address is and can not attempt to send unauthorized data directly to the host in an attempt to access it in a manner which is not desired by the service provider.
The security exposure situation is not improved much through the use of a proxy server, because a hacker who compromises the proxy server can use the proxy server as a base for accessing the provider's hosts. In a typical proxy server environment, the network and any firewalls must "trust" the proxy and allow data communications to flow between the proxy and the host. In other words, hosts must accept data transmitted from a proxy, and firewalls must allow traffic to or from the proxy to users and hosts to flow freely.
As discussed above, in a typical communication session between a user and a host through a proxy server, the proxy server accepts the user's inbound (from user to server) session connection request, and invokes a new session request between the proxy server and the host. Although this arrangement and method hides the host address from the user, a connection is still established
by the proxy server to the host. Thus, any interposing firewalls must allow the proxy to establish a connection with a host. As a result, gaining access to the proxy, authorized or unauthorized, allows access to a provider's host .
Figure 1 shows an example of a typical prior art security hardware arrangement. In a typical environment, such as the Internet, users using client system 2 need to access a service available on host 4 through public network 6. In addition, a person responsible for managing host 4 will access that host using management terminal 8 through private network 10. Public network 6 is a global computer network such as the Internet, whereas private network 10 is a corporation's intra- network. Security device 12 is interposed between public network 6 and private network 10 such that users 2 can communicate with host 4, but are not permitted to communicate with private network 10 or any hosts thereon. Security device 12 can be a firewall or a proxy server. Security device 12 can be configured so that users on private network 10 can access public network 6 or host 4. In the arrangement shown in Figure 1, the placement of host 4 on a network segment accessible by both public network 6 users and private network 10 users is called a demilitarized zone (DMZ) .
As discussed above, the arrangement of Figure 1 leaves open a number of potential security problems, and limits the placement of hosts to these DMZ segments. Using the prior art arrangement, a client system 2 is establishing a direct session with host 4, or a proxied session with host 4 through security device 12. An unauthorized user who gains access to security device 12 may be able to then access private network 10, management terminal 8 and any other devices on the private network. An unauthorized user compromising security device 12 may also be able to access data on host 4 to which he is not entitled because host 4 is typically configured to trust the integrity of data received from security device 12. Thus, this arrangement is problematic from a security standpoint .
In addition, because host 4 and others like it must be placed on DMZ segments, corporate personnel wishing to access host 4 must either do so through security device 12 or must physically go to the location of host 4 to access that host by a directly connected terminal or a terminal on the DMZ segment .
It is desirable to be able to configure security device 12 such that connections originating from private network 10 to host 4 or to public network 6 are not permitted, while simultaneously allowing corporate
personnel to easily access host 4 for maintenance and support .
The distribution and breadth of host-based applications necessitates the ability for the client system to be able to execute customized "front end" applications which communicate with the different hosts across the communications network. Often, the network address, for example the Transmission Control Protocol/Internet Protocol (TCP/IP) address, and logical communication port assigned to a particular application are different for each application. Using multiple logical communication ports requires that the user manage their security hardware and software, for example their firewall, to allow passage of data from the client system 2 to each individual address and logical communication port assigned to the various applications. Using voluminous logical communication ports results in a security exposure due to the voluminous "holes" which must be permitted in the firewall and requires a significant amount of administrative resources to configure the firewalls to allow and deny communication as necessary. Similar configuration changes must be made in the service provider's security device 12.
Although many Internet web sites currently use the default logical communication port 80 for web browser
access, many different logical communication port numbers are created and used to provide more secure paths of communication implementing filtering schemes similar to those described above. Of course, each component in the system adds processing delay, a point of potential failure, requires maintenance and upgrading and adds to the general complexity of the overall system. This situation is especially undesirable to financial institutions who seek to allow users to access only their own account information using a simple, easy to maintain hardware and software configuration and/or access multiple hosts. It is therefore further desirable to provide an efficient system of routing multiple secure application session requests to one or more hosts by allowing a plurality of applications to be executed from a client system to the host in a manner which is efficient and secure.
SUMMARY OF THE INVENTION
The present invention provides a system and method which allows user terminals executing multiple applications to interact with one or more hosts across a communication network via a secured proxy system. In this manner, security mechanisms are employed at the
application level and the session establishment level in a manner which is transparent to the user. Further, the present invention allows the use of multiple applications from the user terminal in a manner which minimizes the quantity of logical communication ports which must be opened on the client firewall and the service provider firewall devices.
The present invention is directed towards a security system for ensuring secure communications between one or more client systems and one or more hosts as well as a communication system incorporating the security system. The invention is also directed towards a process for securely transmitting information between the one or more client systems and the one or more hosts. According to a first aspect of the present invention, the communication system comprises:
(A) one or more client systems;
(B) one or more hosts, each host providing one or more services ,- (C) a security system interposed between the client systems and the hosts for controlling communications between the client systems and the hosts, the security system including:
(1) a server having a plurality of server sockets, each server socket corresponding to a different one of the services; and
(2) a firewall coupled between the client systems and the server and receiving a plurality of requests for different services from the client systems on a first socket of the firewall; and
(3) one or more software modules, at least some of the software modules examining each respective one of the requests received on the first socket of the firewall and causing it to be forwarded to that socket on the server which corresponds to the service requested.
In the preferred embodiment, the firewall also receives a plurality of requests for services from the client systems on a second socket of the firewall. All of the requests received on the first socket of the firewall are for services that are different than the services being requested by the requests received on the second socket of the firewall. At least one of the software modules examines each of the requests received on the second socket of the firewall and causes it to be forwarded to that socket on the server which corresponds to the service requested.
The client systems and hosts preferably communicate with one another using information packets. Each request
is preferably received in the form of one or more of the information packets. All of the information packets relating to a first group of services are sent to the first socket of the firewall and all of the information packets relating to a second group of services are sent to the second socket of the firewall.
In the preferred embodiment, all of the information packets sent to the first socket of the firewall are encrypted according to a first encryption method and all of the information packets sent to the second socket of the firewall are encrypted in accordance with the second encryption method. At least one of the software modules preferably decrypts the information packets before they are sent to the appropriate host . In the preferred embodiment, the security system includes a pair of servers and a pair of firewalls. In addition to the foregoing first server and first firewall, a second server is provided which communicates with the hosts over a communication network and a second firewall is provided which is coupled between the first and second servers. The second server sends a host mapping table to the first server which maps the services provided by the various hosts to a specific mapping numbers which are used by the second server to identify, for each service, the respective socket on the hosts
which corresponds to the service requested. In the preferred embodiment, the first server sends information packets to the second server along with an indication of the mapping number and the second server then sends the information packets to the socket on the hosts which corresponds to the mapping member.
The present invention is also directed towards a security system having one or more of the above noted features . The present invention is further directed towards a process for controlling communications between one or more client systems and one or more hosts via a security system coupled between the one or more client systems and the one or more hosts. Each of the hosts provides one or more services . The security system includes a server having a plurality of server sockets, each server socket corresponding to a different service, and a firewall located between the client systems and the server. The process comprises: forwarding a plurality of requests for different services from one or more of the client systems to a first socket of the firewall; and examining each request received on the first socket of the firewall and forwarding it to that socket on the server which corresponds to the service requested.
A plurality of requests for different services are preferably forwarded from one or more of the client systems to a second socket of the firewall. All of the services requested by the requests received on the first socket of the firewall are preferably different than all of the services requested by the request received on the second socket of the firewall. Each of the requested services received on the second socket of the firewall is examined and caused to be forwarded to that socket on the server which corresponds to the service requested.
Communications between the client systems and the hosts are preferably via information packets and the requests are preferably forwarded in the form of information packets. All of the information packets relating to a first group of services are preferably with a first encryption method and sent to the first socket of the firewall. All of the information packets relating to a second group of services are preferably encrypted in accordance with a second encryption method and are sent to the second socket of the firewall. In both cases, it is preferred that the information packets be decrypted before they are sent to the host .
In the preferred embodiment, the security system used by the process further includes a pair of firewalls and a pair of servers. In addition to the first firewall
and first server described above, the security system includes a second server which communicates with the hosts over a communication network and a second firewall coupled between the first and second servers. The process preferably sends a host mapping table from the second server to the first server, the host mapping table mapping the services provided by the hosts to specific mapping numbers which are used by the second server to identify, for each such service, the respective socket on the hosts which corresponds to the service in question. Information packets are preferably sent from the first server to the second server along with an indication of the mapping number corresponding to the service in question and information packets are sent from the second server to the socket on the host which corresponds to that mapping number.
Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings .
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a diagram of a prior art security hardware arrangement ;
Fig. 2 is a diagram of the security hardware arrangement of the present invention;
Fig. 3 is a flowchart showing a secure session establishment process of the present invention; Fig. 4 is a diagram of an alternate embodiment of the security hardware of the present invention;
Fig. 5 is a flowchart of a secure session establishment process from client system 2 to host 4 of the present invention; Fig. 6 is a flowchart of a secure session establishment process of the present invention from host 4 to client system 2.
For the purpose of illustrating the invention, there is shown in the drawings a form which is presently preferred, it being understood, however, that the invention is not limited to the precise arrangement shown .
DETAILED DESCRIPTION OF THE INVENTION The following detailed description uses the terms "inbound" and "outbound" when referring to the flow of data communication traffic such as actual data payload and request/response data. As used herein, the term "inbound" refers to communication data originating at a public client system, such as client system, and
terminating at a service provider's security system device or host. Conversely, "outbound" traffic refers to traffic flowing from the host or security system to a client system in public network. Also, the term "port" as used herein refers to a logical communication port established via software such as a TCP/IP port. The term "socket" as used herein refers to its common computer programming usage in which a "socket" is a logical end point in a connection, including logical connections between processes running within the same computer (i.e., the IP address of the host and the port number of the service corresponding to that port) . The connection, however, can be "connectionless" in the context of global networking such as the Internet in which a server supports many client requests but does not maintain the actual connection any longer than is necessary to service the immediate request. The term "thread" as used herein refers to its common computer programming usage in which a "thread" is a routine within a program which operates as a placeholder used to support multiple concurrent users of a single executing instance of a computer program.
With reference to the Figures in which like reference numerals refer to like elements, Fig. 2 shows
the hardware arrangement according to a first embodiment of the present invention.
As shown in Figure 2, security system 14 of the present invention is comprised of external firewall 16, public proxy server 18, internal firewall 20 and private proxy server 22. In the depicted arrangement, external firewall 16 is connected to public network 6 and to public proxy server 18. Public proxy server 18 in turn is connected between external firewall 16 and internal firewall 20. Public proxy server 18 can sit on an isolated segment such that there are no other devices attached or networked between public proxy server 18 and external firewall 16 on the outbound side, and public proxy server 18 and internal firewall 20 on the inbound side. Private proxy server 22 connects internal firewall 20 to private network 10. Thus, physical connectivity from client system 2 to host 4 is as follows:
Client system 2 Public Network 6 External Firewall 16 Public proxy server 18 Internal Firewall 20 Private proxy server 22 Private Network 10 Host 4.
Although a physical path is provided between client system 2 and host 4, it should be noted that the logical flow of data and session establishment using the present
invention does not allow client system 2 to directly establish a service session with host 4.
External firewall 16 is a typical packet or session firewall which is configured to allow inbound access to specific logical ports, i.e. host services via TCP/IP ports, by allowing those connections to be made between client system 2 and public proxy server 18.
Internal firewall 20 can be a router or other typical device capable of packet filtering or session filtering, and is configured to only allow gateway proxy server 22 to initiate an outbound service connection to public proxy server 18 using a predetermined group of logical ports, such as TCP/IP port 8080. Internal firewall 20 is configured to deny and filter out any inbound connection requests, for example, connection requests originating at public proxy server 18, external firewall 16, public network 6 or client systems 2 which attempt to establish a service connection to private proxy server 22, private network 10 or host 4. As is described below, internal firewall 20 is configured to allow data flow between public proxy server 18 and private proxy server 22, but internal firewall 20 is configured such that only data communications between public proxy server 18 and private proxy server 22 are
permitted once private proxy server 22 establishes a connection to public proxy server 18.
Hosts 4 and client systems 2 are typical devices suitable for performing the functions required of host and client systems respectively. For example, each client system 2 can be a personal computer or hand held computer device capable of accessing a global computer network such as the Internet . Each host 4 can range in size and capability from a personal computer to a mainframe computer, and is sized according to the service provider's particular requirements. Also, each host 4 can be logically and physically located anywhere within private network 10.
The computing hardware platforms for public proxy server 18 and private proxy server 22 are typical personal computer servers or UNIX servers sized such that they can handle the expected user and data traffic load. For example, public proxy server 18 and private proxy server 22 can be servers running MICROSOFT'S WINDOWS NT operating system. Thus, public proxy server 18 and private proxy server 22 need not contain any special operating system enhancements in order to function as proxy servers in the present invention. However, public proxy server 18 and private proxy server 22 do contain special software which enables these devices to function
as an integral part of the present invention. The control programs running on public proxy server 18 and private proxy server 22 can be written in any language suitable for programming, such as C++, or JAVA. Upon system initialization, the private proxy server 22 requests a connection to the public proxy server 18. When the connection is first requested, the private proxy server 22 sends a file through internal firewall 20 and to a designated server socket (IP address and logical communication port) on the public proxy server 18. For simplicity, this connection is designated herein as the main proxy control connection. The private proxy server 22 thereafter waits for a connection reply from the public proxy server 18 over the main proxy control connection. As will be described below, this reply will be a request from one of the client systems 2 for access to a particular service provided by one of the hosts 4.
The file initially sent by the private proxy server 22 to the public proxy server 18 comprises a table of services, for example checking account services, mortgage services, branch locations, etc., offered by the various hosts 4. This table is designated herein as the host mapping table. Each service listed in the host mapping table is identified by a respective unique value, and each value includes a corresponding logical communication
port on a given host 4. The host mapping table is essentially a look-up table of valid host-provided services and corresponding host logical communication ports. The host mapping table sent to public proxy server 18 does not actually identify the socket (the combination of the IP address and port) on which the service resides. As such, someone obtaining access to the public proxy server 18 cannot identify the actual socket on which the service is running. However, each port in the host mapping table will have a one-to-one correspondence with a specific socket on one of the hosts 4. The private proxy server 22 knows this correspondence and, when it receives a port number from public proxy server 18, can identify the actual socket (host IP address and logical communication port) on which the service is running. In the preferred embodiment, the port in the host mapping table corresponds to the actual port (but not IP address) on which the service is running. This is not, however, necessary. Any mapping of an arbitrary number to the desired service can be used in the host mapping table as long as the private proxy server 22 knows how to correlate that arbitrary number to the actual socket on which the service is running. However configured, the public proxy server 18 uses the host mapping table to identify specific ports on hosts 4
which correspond to application services requested by client systems 2.
After the private proxy server 22 initially sends the host mapping table to the public proxy server 18, the private proxy server 22 waits for a reply from the public proxy server 18 over the main proxy control connection. The public proxy server 18 will send a reply to the private proxy server 22 only after a request from a valid client system 2 and for a valid host provided service is received. For example, a client system 2 requests a service (e.g., checking account information) provided by a host application and designates the service simply as 111 (a number which the client system 2 has been told to use to identify the particular service in question) . The public proxy server 18 receives the request for service 111 and references the host mapping table to look up the corresponding host logical communication port, for example 8050. Port 8050, in this example, refers to the port number of the particular host 4 (the public proxy server 18 does not know which one) on which service 111, checking account information, is being run.
A client system's request for a service provided by a host 4 can be initiated automatically while running a software program on the client system 2. Alternatively, a service request can be manually entered into the client
system 2 by the user, for example by typing a URL or by clicking on a hyperlink. In either case, the client system 2 will reference a domain name service ("DNS") entry table to identify a specific socket on external firewall 16 corresponding to that service. The socket identified by the DNS entry is the endpoint on external firewall 16 where client system requests are forwarded. A unique socket exists on the external firewall 16 for each host provided service available for client system applications. If there are twenty host provided services, there will be twenty respective sockets on the external firewall 16. For example, if a client system 2 requests checking account information, designated above as service 111, the DNS entry may point to socket "315.245.235:7111" on external firewall 16 (the IP address 315.245.235 identifying the firewall 16). Alternatively, if a client system requests customer demographic information, designated as service 222, the DNS entry may point to socket "315.245.235:7222." Once the request comes in to external firewall 16, the client system's socket is identified and, if that client system is accepted as an authorized client system, the request is forwarded through the external firewall 16 to the public proxy server 18.
Most of the sockets configured on the external firewall 16 have corresponding sockets on the public proxy server 18. Authorized client system requests are forwarded through the external firewall 16 to corresponding sockets on the public proxy server 18. The public proxy server 18 references the socket that a client system request is received on to identify a corresponding host provided service. In other words, by identifying the specific socket that the public proxy server 18 has received a connection request on, the public proxy server 18 knows which specific host provided service the client system 2 application wants.
As an inherent function of TCP/IP, whenever a connection request is received and accepted on a socket, a new session is automatically created. The session is identified by the client's socket, the receiving system's socket, and the communication protocol, for example TCP, that is used. The receiving system returns the new session information to the sending system and transmission continues on the newly created session. In the example cited above, the public proxy server 18 stores the socket that a request is received on in memory, and then creates a new session. The socket used for this session is designated herein as socket SI .
Continuing with the checking account example cited above, once the public proxy server 18 identifies host port 8050 for service 111 (checking account information) , additional data is stored in the memory on public proxy server 18. The type of data stored preferably includes the IP address of the requesting client system 2, the logical communication port of the requesting client system 2, the logical communication port of the public proxy server 18, the communication protocol used (e.g., TCP) and a unique index number identifying the requesting client system 2. The index number is used as a short hand way for the public proxy server 18 and the private proxy server 22 to identify the client system 2 which requested the service. As a result, the private proxy server 22 need not know the actual IP address of the client system 2, thereby reducing security, memory and processing requirements. Other data regarding a client system 2 can be stored on the public proxy server 18 as needed. Having stored this data, the public proxy server 18 replies to the initial connection request from the private proxy server 22 over the main proxy control connection by requesting a connection to a specific host port number on which the desired service is located. Particularly, the public proxy server 18 forwards data
including both the destination host port number identifying the particular service requested and the index (i.e., identity) of the requesting client system 2 to the private proxy server 22 as a server response packet from the system initialization request.
The private proxy server 22 references the host port number received from the public proxy server 18 and uses it to identify the socket (IP address and logical communication port) of the host 4 that corresponds to the specific requested service. Upon receiving the reply sent by public proxy server 18, the private proxy server 22 creates a new session (as an inherent function of TCP/IP) and sends the information regarding the session to the public proxy server 18. The socket on the private proxy server 22 used for this session is designated herein as socket S2.
When the private proxy server 22 identifies the host socket corresponding with the service the client system 2 is requesting, the private proxy server 22 sends a connection request to the appropriate host 4. The host 4 receives the connection request and sends a reply to the private proxy server 22 and completes the connection. A new session is thereby created between the private proxy server 22 and the host 4. The socket on the private
proxy server 22 used to communicate with the host 4 is designated herein as socket S3.
The connection reply originating from the host 4 is forwarded by the private proxy server 22 to the public proxy server 18. The public proxy server 18 receives the reply and creates a new session (as an inherent function of TCP/IP) . The public proxy server 18 sends the new session information to the private proxy server 22 for continued transmission. The socket on the public proxy server 18 used to communicate with the private proxy server 22 is designated herein as socket s4.
The sessions described thus far are used for secured transmission between the requesting client system 2 and the responding host 4. In addition, programming threads are implemented throughout the process to enable the transmission of data to and from the above-described sockets. For example, a client system 2 connects to socket SI on public proxy server 18, a thread ties SI to S4 on the public proxy server 18, socket S4 on public proxy server 18 connects to socket S2 on private proxy server 22, a thread ties S2 to S3, and S3 on private proxy server 22 connects to destination host-system 4. Once the logical connection path is established between the originating client system 2 and the application server (i.e., the host 4 running the application),
transmission and reception of information between the client system 2 and the host 4 occurs via public proxy server 18 and private proxy server 22.
Fig. 4 illustrates an example of a second embodiment of the hardware layout of the present invention. Fig. 4 is similar to the first embodiment as shown in Fig. 2, but further includes client firewall 32 and security host 34. Client firewall 32 is coupled to client systems 2 and to public network 6. Security host 34 is coupled to private network 10 on the host side of internal firewall 20.
Client firewall 32 is a typical packet or session firewall which is configured to allow inbound access to specific sockets, i.e. IP addresses and logical communication ports, by allowing connections to be made between client system 2 and public proxy server 18. Security host 34 is preferably a CPU based device which authenticates users and authorizes or denies user access to application resources residing on hosts 4. In the system illustrated in Fig. 2, multiple sockets on external firewall 16 are configured, opened and closed when requests for host provided services are sent by client systems 2. Each socket on external firewall 16 corresponds to a single, respective, available service provided by the hosts 4. For example,
after a client system 2 connection request is sent, the socket on external firewall 16 which correlates with the requested service is opened. When another client system connection request is made for a different service, a different socket, corresponding to the second service is opened. If twenty services are requested, twenty sockets are opened. The multitude of sockets on external firewall 16 corresponding to host provided services present numerous potential security "holes" and excessive resource overhead.
The embodiment of Fig. 4 overcomes these problems by removing the requirement for a one-to-one correspondence between host application services and sockets on the external firewall 16. In accordance with the invention, a single socket will receive connection requests for a plurality of different services and each connection request will be forwarded to the appropriate socket on public proxy server 18. In the preferred embodiment all connection requests are encrypted using one of two different encryption methods and a separate socket on firewall 16 is provided for each encryption method. Each service typically requires a respective encryption method. Requests for those services requiring a first of the encryption methods are sent to the single socket on firewall 16 corresponding to that encryption method.
Requests for those services requiring the second of the encryption methods are sent to the single socket on firewall 16 corresponding to that encryption method. While any encryption methods can be used, the two presently preferred encryption methods are the Secured Sockets Layer ("SSL") method and the Digital Signal ("DS") method. Both of these methods are well known in the art and will not be described further. The two corresponding sockets on firewall 16 will be referred to hereinafter as the SSL socket and the DS socket, respectively.
Before the actual request for service (requesting a connection between the client system 2 and the host 4) is sent, the invention preferably employs a user authentication system which confirms that the particular user utilizing the client system in question is authorized to have access to the particular service being requested. Any desirable authentication method, for example, the use of Lightweight Directory Access Protocol ("LDAP"), can be used. All requests for user authentication are sent to a separate dedicated socket on firewall 16. This socket will be referred to hereinafter as the "LDAP" socket.
Once the appropriate authorization system (e.g., LDAP) , has confirmed that the user is entitled to access
the service in question, a request for service is sent to the appropriate socket (the SSL socket or the DS socket) on the external firewall 16. In a manner described in greater detail below, this request is then forwarded to the appropriate socket on public proxy server 18. Each of the sockets on public proxy server 18 have a one to one correspondence to the particular service requested. At this point, a connection between the client system 2 and the appropriate host 4 is established in the manner described above with respect to the embodiment of Fig. 2. In the preferred embodiment, all information sent between the client systems 2, the security system 14, and the hosts 4 are sent in the form of information packets. The information packets take at least three forms: request for authorization packets, request for connection packets and data packets. The request for authorization packets are sent to the LDAP socket to request authentication of the user requesting a particular service. The request for connection packets are sent to the DS or SSL socket, depending upon the type of encryption method used. As described above with respect to the embodiment of Fig. 2, once an actual connection has been made between any of the client systems 2 and the host 4, they will take place over the same sockets but a new set of sessions created for the particular connection
in question. The manner in which the preferred embodiment ensures that connection requests are properly routed through firewall 16 to public proxy server 18 will now be described. Upon initialization of a client system 2, a program module (the Event Listener Module) is started which waits for and eventually intercepts requests for host services made by applications running on client system 2.
When first started, the Event Listener reads a configuration file which contains data corresponding to variables stored in the Event Listener's instruction set. There are essentially three categories of data contained in the configuration file. One category of data contains values identifying the (three) sockets on the external firewall 16. A second category identifies the multitude of sockets on public proxy server 18, each of which corresponds with a respective service provided by hosts 4. A third category of data in configuration file comprises directives for the types of encryption methods to be used.
During the course of processing, a client system 2 application will formulate a request for a specific service on one of the hosts 4. The Event Listener intercepts the request and uses the data stored from the configuration file to identify the appropriate encryption
method and destination sockets (i.e., the socket on firewall 16 and the socket on public proxy server 18) to be used for the request for connection packet for the service requested. The Event Listener proceeds to write a request for connection packet for the service being requested and, in the preferred embodiment, forwards it to additional program modules (preferably processed by user terminal 2) for further processing.
These modules perform tasks such as encrypting the request for connection packet, embedding data in the request for connection packet identifying the specific service requested and forwarding the request for connection packet through the client firewall 32 to the appropriate destination socket (SSL socket or DS socket) on the external firewall 16. While separate modules are presently preferred, the Event Listener can perform all of the processes without the need for separate program modules .
It is important to note that only a limited number of sockets are configured, opened and closed on external firewall 16. Rather than providing a separate socket for each service, the preferred embodiment provides one socket for LDAP connections, one socket for data packets encrypted using SSL and one socket for data packets encrypted using Digital Signature.
Prior to being received by the public proxy server 18, the encrypted request for connection packets received by external firewall 16 are forwarded to program modules for decryption. These program modules are processed on any convenient processor which may be the computer on which the public proxy server 18 is running. For example, a packet encrypted using Digital Signature is forwarded through the external firewall 16 to a Digital Signature decrypting module. Conversely, if a data packet is encrypted using SSL, then the packet is forwarded from the external firewall 16 to an SSL decrypting module. The external firewall 16 consistently forwards packets to the proper modules because the socket which received a packet is referenced to determine where to forward the packet. For example, request for connection packets which arrive on the SSL socket will always be forwarded to the SSL decrypting module for decryption.
Once the request for connection packet is decrypted, it is forwarded to yet another program module (again processed on any convenient processor) referred to herein as the Connector. The Connector module reads the decrypted, unsecured data in the packet sent by the Event Listener and determines the appropriate socket on the public proxy server 18 where the request for connection
packet should be forwarded (i.e., the socket corresponding to the requested service) . When the Event Listener initially wrote the request for connection packet, it included information from the configuration file that indicated the appropriate destination socket on the public proxy server for the packet. The Connector module uses this information to forward the packet to the appropriate socket on public proxy server 18.
Once the data packet is forwarded to the public proxy server 18 on the socket correlating with the desired host provided service, the public proxy server 18 uses the host mapping table previously received from the private proxy server 22 to identify the host port that correlates with the requested service. The public proxy server 18 sends this host port to the private proxy server 22 which then identifies the actual host socket on the appropriate host 4 and sends the connection request to that host .
The appropriate host 4 preferably replies to the connection request and the reply is sent to the private proxy server 22, and then to the public proxy server 18 for eventual delivery to the appropriate client system 2.
When a connection reply has been sent back to the public proxy server 18, the reply is not forwarded to a corresponding port on external firewall 16. Instead, the
packet is sent back to the Connector module which reads the data in the packet and determines the encryption method to apply to the packet . The Connector module preferably forwards the packet to an encrypting program module and the appropriate encryption method is employed on the data packet. Once encrypted, the data packet is forwarded through external firewall 16 using the existing session established during the connection.
The external firewall 16 forwards the packet through global communication network 6, through client firewall 32 and to a program module residing on client system 2 designed for decrypting the packet. In the preferred embodiment, one program module is dedicated for packets encrypted with SSL, and a different module is dedicated for packets encrypted with Digital Signature.
Alternatively, one program module can be employed to decrypt all data packets.
The decrypted, unsecured packet is forwarded to yet another program module (preferably running on client system 2) which reads the connection reply and forwards the reply to the requesting application on the client system 2. At this point, a connection is established between the requesting client system 2 and the replying host 4, and by employing the Event Listener and Connector modules, only three logical endpoints, or sockets, are
required to be configured, opened and closed on external firewall 16.
While many different sockets may be required by the requesting client systems 2 for the variety of applications running on hosts 4, the security risk and configuration issues are eliminated by the current invention as it uses the existing proxy portal at the customer's site and three port openings on external firewall 16 for LDAP, SSL and Digital Signature. An example of the communication process, including the interaction between the modules is now described with reference to flowcharts in Fig. 5 and Fig. 6.
Upon starting the process of the present invention, Event Listener reads the configuration file to obtain a listing of security encryption protocols and communication sockets (Step S102) . During the course of execution of one or more application programs, client system 2 formulates a connection request (Step S104) . The Event Listener module intercepts client system 2 connection request, and thereupon wraps the connection request, and writes a new data packet (Step S106) . Methods for wrapping data in packets are known.
Once the request is intercepted from client system 2, the Event Listener module transmits a request to the
LDAP security host 34 for user authentication (Step S108) . These measures ultimately result in either authorization or rejection of the connection request as described above and similarly in the continuation or termination of the communication process.
Once the connection request is intercepted by the Event Listener module and wrapped in the data packet, the packet is encrypted (Step 110) . As described above, the type of security protocol applied to the packet, for example SSL or Digital Signature, is based on the entries in the configuration file. Once the connection request has traversed client firewall 32, global communication network 6 and external firewall 16, the request is decrypted and received by the Connector module (Step S112) . The Connector module forwards the request to the public proxy server 18 (Step S114) . The public proxy server 18 forwards the request through a single logical communication port on internal firewall 20 and the packet is received by private proxy server 22 (Step S116) . Private proxy server 22 forwards the request to host 4 (Step S118) .
Once host 4 has received and processed the request for a connection from client system 2, a response is transmitted through internal firewall 20 to private proxy server 22 and to public proxy server 18 (Step S120) . The
packet is then forwarded to the Connector module and then encrypted (Step S122) . The response traverses external firewall 16, global communication network 6 and then through client firewall 32 to be received and decrypted and then forwarded to the requesting application on the client system 2. (Steps S124-S130) .
Thus, security system 14 and its accompanying procedure for establishing secure communications is provided by the present invention. In particular, a service provider's hosts 4 are protected from attack from users in public network 6 because internal firewall 20 does not allow initial service connections originating from its public network side. The initial main proxy control connection is initiated from the private network side of internal firewall 20 by private proxy server 22, connecting outward to public proxy 18. This allows internal firewall 20 to be configured to deny all inbound connection initiation requests. Thus, even if a hacker were able to compromise external firewall 16, or even public proxy server 18, the hacker would be unable to jump from public proxy server 18 to internal firewall 20, private proxy server 22 or any device attached to private network 10, because internal firewall 20 in configured to deny those requests. In addition, even once a forwarded connection request has been accepted by a host 4, Step
S38 requires that another outbound connection from private proxy server 22 to public proxy server 18 be established to create the actual data payload connection which will eventually be used to transport data to and from client system 2 to host 4.
Also, security system 14 and the session establishment procedure of the present invention allow service providers to position hosts 4 anywhere within private network 10 such that host 4 need not be installed and supported on a DMZ network segment . The present invention provides this facility because actual data flow between client system 2 and host 4 is segmented into smaller connections, i.e. via the previously described socket and thread communication connections. This allows for effective and efficient management of hosts 4 by the service provider and decreases the costs associated with providing the services .
The present invention employs the use of software modules executing on client system 2 which provide seamless integration with the firewalls and proxy servers provided by the service provider. In particular, these software modules function to allow multiple applications executing on client system 2 to access a destination host 4 using a single or minimal number of TCP/IP addresses
and logical ports while simultaneously providing application level security and encryption services. The present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof and, accordingly, reference should be made to the appended claims, rather than to the foregoing specification, as indicating the scope of the invention.