Patent Description:
Security of data communications is a primary concern to users of the internet and other computer networks. Bad actors are known to infiltrate computer systems to steal data, harm systems, or modify functionality. Current computer systems, particularly highly active servers, are open to such attacks.

<CIT> entitled "Secure client/server data transmission system" describes a central server that maintains connections between client machines and server machines.

<CIT> entitled "Systems and methods for establishing connections between devices communicating over a network" describes a system of relay servers that provide connections between clients and servers. The document <CIT>), discloses a system for securing network connections between computing devices by controlling access to a third computer via an intermediary. The document <CIT>), describes a firewall-bypassing communication system for streaming data between devices using WebSocket and HTTP bridges.

The present invention relates to a system, a bridge device and a server, according to the annexed claims.

According to an aspect of the present invention, a system includes a plurality of computer devices connected to a network. The computer devices are operable by a plurality of users. The system further includes a server connected to the network. The server is to communicate data with the plurality of computer devices. The system further includes a bridge device connected to the network. The bridge device is to receive connection requests from the plurality of computer devices via the network. The bridge device is further to receive connection requests from the server via the network. The bridge device is further to mediate data communications between the plurality of computer devices and the server by communicating data through open connections made based on connection requests received from the plurality of computer devices and the server. The bridge device includes an index of servers to bridge devices, wherein the bridge device is to use the index to determine an identifier of another bridge device to provide data communications between a particular computer device of the plurality of computer devices and the server, and wherein the bridge device is to communicate the identifier of the other bridge device to the particular computing device.

All inbound ports to the server may be closed.

The system may further include a router, switch, or firewall that connects the server to the network. The router, switch, or firewall may have all inbound ports closed.

The bridge device may provide encrypted data communications between each of the plurality of computer devices and the server.

According to another aspect of the present invention, a bridge device includes a communications interface to connect to a network, memory, and a processor connected to the memory and the communications interface. The processor is to receive connection requests from a plurality of computer devices via the network. The processor is further to receive connection requests from a server via the network. The processor is further to provide data communications between the plurality of computer devices and the server through open connections made based on the connection requests received from the plurality of computer devices and the server. The processor is to use an index an index of servers to bridge devices to determine an identifier of another bridge device to provide data communications between a particular computer device and the server, and wherein the processor is to communicate the identifier of the other bridge device to the particular computing device.

The processor may not transmit connection requests to the server.

The processor may provide encrypted data communications between each of the plurality of computer devices and the server.

The memory may store public encryption keys for the plurality of computer devices and the server.

The bridge device may further include a correlation table to correlate connections with the plurality of computer devices to connections with the server.

According to another aspect of the present invention, a server includes a communications interface to connect to a network, memory, and a processor connected to the memory and the communications interface. The processor executes an application. The server further includes a connection agent to make connection requests to a bridge device. The connection agent is further to communicate data between the application and the bridge device over an open connection. The bridge device, to which the connection agent makes the connection, is identified at an index of servers to bridge devices, wherein the index correlates the server to the bridge device, and wherein an identifier of the bridge device is shared with computer devices intending to access the application.

The connection agent may initiate a new connection request to the bridge device when all existing connections are in use.

The connection agent may close an inactive connection with the bridge device.

The present invention aims to reduce or eliminate the ability to infiltrate a computer server or other endpoint. A bridge device manages communications between endpoints, such as user computers and a server. The bridge device responds to requests from endpoints. The bridge device does not issue requests to a server that is expected to experience infiltration. Rather, the bridge device responds to requests from the server. Accordingly, all inbound ports of the server or its supporting network infrastructure (router, switch, firewall, etc.) may be closed to new connections. As such, the server or its supporting network infrastructure initiates new connections with the bridge device. The bridge device, or any other device for that matter, cannot initiate a new connection to the server, as all inbound ports of the server or its supporting network infrastructure are closed. An attacker targeting the server will find all inbound ports closed and will be unable to make new connections to the server. Hence, the server will be less likely to be infiltrated.

<FIG> shows an example system <NUM>. The system <NUM> includes a plurality of computer devices <NUM>, a server <NUM>, and a bridge device <NUM>. All components may be interconnectable via a network <NUM>, such as the internet. The computer devices <NUM> and server <NUM> are examples of endpoints and other examples are contemplated.

The computer devices <NUM> are operable by a plurality of users. The computer devices <NUM> may include notebook computers, smartphones, desktop computers, servers, or any other computer device operable by a user.

The server <NUM> is to communicate data with the computer devices <NUM>. Examples of servers include web servers, database servers, image hosting servers, email servers, messaging servers, file storage servers, social network servers, enterprise servers, and the like. Any number of cooperating servers <NUM> may be provided.

The bridge device <NUM> is to receive requests from the computer devices <NUM> via the network <NUM>. The bridge device <NUM> may have one or more inbound ports open to accept such requests. The bridge device <NUM> is also to receive requests from the server <NUM> via the network <NUM>. Such requests may be configured to initiate new connections with the bridge device <NUM>. Connection requests may accord to any suitable protocol, such as HTTP, HTTPS, and the like. Connections may accord to any suitable protocol, such as TCP/IP.

The bridge device <NUM> responds to requests by, if appropriate, accepting a new connection request and opening a connection with the requesting endpoint, such as a computer device <NUM> or server <NUM>. Once a connection is established with an endpoint, bidirectional communication of data between the bridge device <NUM> and that endpoint may occur. As such, bidirectional communication of data between two endpoints, such as a computer device <NUM> and a server <NUM> may be mediated by the bridge device <NUM> through two separate connections at the bridge device <NUM>.

Establishing a new connection is at the request of the endpoint, such as a computer device <NUM> or server <NUM>. The bridge device <NUM> may respond with an acceptance of a new connection. Hence, new connection requests are unidirectional and inbound to the bridge device <NUM>. An established connection, of course, allows for bidirectional data communications between the bridge device <NUM> and the respective endpoint <NUM>, <NUM>.

Any endpoint may have all inbound ports closed. Specifically, the server <NUM> or its supporting network infrastructure (router, switch, firewall, etc.) <NUM> may have all inbound ports closed. As such, the server <NUM> or its supporting network infrastructure <NUM> refuses all new connection requests. Any connection-related functionality attributed herein to a server <NUM> may be instead carried out by the server's supporting network infrastructure <NUM>.

The computer devices <NUM> and the server <NUM> may be provided with the network address of the bridge device <NUM>, so as to facilitate new connection requests outbound from the computer devices <NUM> and the server <NUM>. Such a network address may be an IP address.

In various scenarios, user-controlled endpoints, such as the computers <NUM>, may initiate connections to an endpoint, such as a server <NUM>. As such, connection requests from the computer device <NUM> may be user-initiated. For example, a user may direct a web browser or other user agent to connect to a web server or other type of server. The computer device <NUM> may then connect to the bridge device <NUM>. On the other hand, endpoints that are not directly controlled by users, such as the server <NUM>, may periodically issue new connection requests to the bridge device <NUM>. The bridge device <NUM> may maintain an open connection with a server <NUM> and may assign the open connection to a new connection accepted from a computer device <NUM> that may a request to connect to that server <NUM>. The server <NUM> may monitor its own connections to the bridge device <NUM> and may issue a new connection request to the bridge device <NUM> if all established connections are in use. The bridge device <NUM> may accept new connections from endpoints and may keep alive such connections, while matching established connections to endpoints attempting to communicate with each other.

A bridge device <NUM> may provide encrypted data communications between each of the computer devices <NUM> and the server <NUM>. To facilitate this, the bridge device <NUM> may store public encryption keys of the computer devices <NUM> and the server <NUM>. The bridge device <NUM>, computer devices <NUM>, and the server <NUM> may each store their respective private keys that are not shared with other entities. Thus, information communicated by the server <NUM> may be encrypted by the server <NUM> using the server's private key. The bridge device <NUM> may then decrypt such information using the server's public key and then encrypt such information using the computer device's public key. The bridge may then transmit the information to the computer device <NUM>, which may then decrypt the information using its private key. In some examples, the information encrypted in this manner is routing information or metadata about a request or response. In such examples, point-to-point encryption between the server <NUM> and computer device <NUM> may be used to prevent data from being visible to the bridge device <NUM>. That is, a data payload may be encrypted according to a scheme/key agreed by a computer device <NUM> and server <NUM>. Then, routing information and/or metadata about the payload may be combined with the encrypted payload. The combined packet may then be encrypted according to a scheme/key known to the bridge device <NUM>. As such, the bridge device <NUM> may access the routing information and/or metadata but not the payload, which remains private to the computer device <NUM> and server <NUM>.

As shown in <FIG>, a plurality of bridge devices <NUM> may support a plurality of servers <NUM>. A given bridge device <NUM> may support a subset of all servers <NUM>. Accordingly, a bridge device <NUM> may maintain a list of servers supported by other bridge devices <NUM>. A bridge device <NUM> may be responsive to request to connect to unsupported servers <NUM> by redirecting such request to an appropriate bridge device <NUM>.

<FIG> shows an example list or index of supported servers <NUM> that is stored by a bridge device <NUM> to assist in routing new connection requests to appropriate bridge devices <NUM>. Each bridge device <NUM> may store such an index.

The index may associate server identifiers <NUM> with identifiers <NUM> of bridge devices <NUM> that are known to receive and maintain connections with various servers <NUM>. A server identifier <NUM> may include a network address, such as an IP address, a URL, domain name, or the like. A server identifier <NUM> may be provided in a request made by a computer device <NUM>. The bridge device <NUM> that receives the request from the computer device <NUM> may then refer to the index to look up a bridge device <NUM> that may be used to communicate with the server <NUM> identified in the request. The bridge device <NUM> that receives the request may itself maintain a connection with the requested server <NUM> and this may also be reflected in the index. A bridge identifier <NUM> may include a unique name/ID for each bridge device <NUM>, such as "demo1. vpz" and may additionally or alternatively include a network address for the bridge device <NUM>, such as an IP address, a URL, domain name, or the like and/or routing information to communicate with the bridge device <NUM>.

Indexes at different bridge devices <NUM> may be different. The bridge devices <NUM> may share their indexes regularly, periodically, or according to another methodology. A bridge device <NUM> may update its index according to an index received from another bridge device <NUM>. In other examples, a master index is stored at a server and all bridge devices <NUM> obtain a copy of the master index or a portion thereof.

Routing of data through bridge devices <NUM> may be optimized to reduce latency and/or error rate. As shown in <FIG>, performance data <NUM> may be stored in an index of server identifiers <NUM> and bridge identifiers <NUM>. A bridge device <NUM> may monitor latency, error rate, or other performance information of data communicated overs its connections. When the same server <NUM> is accessible via multiple other bridge devices <NUM>, the bridge device <NUM> receiving the request may then communicate the request to a better performing bridge device <NUM>. The bridge device <NUM> may additionally or alternatively communicate to the requesting computer device <NUM> the identifier of the better performing bridge device <NUM>, so that the computer device <NUM> may make the next request for the same server directly to the better performing bridge device <NUM>.

As shown in <FIG>, a bridge device <NUM> may maintain a correlation table of its connections. A connection with a particular computer device <NUM> may be correlated to a connection with a particular server <NUM>. The bridge device <NUM> may therefore route data communications appropriately according to the correlation table. In the example depicted, the bridge device <NUM> may assign a connection identifier to two connections to two endpoints (e.g., #<NUM> and #<NUM>) that are in communication. Endpoint connections may be tracked by network address, hostname, IP address, port number, socket, and/or similar information. Further, the bridge device <NUM> may also track open but unused connections that may be opened in response to requests received from servers <NUM>. Such connections (e.g., shown as endpoint #<NUM> connections not mapped to endpoint #<NUM> connections) may be kept alive without actual data transfer until such time that a computer device <NUM> requests information from such a server <NUM>.

The bridge device <NUM> may format an outbound communication with an endpoint <NUM>, <NUM> to appear as if the outbound communication originated from the respective endpoint <NUM>, <NUM>. That is, bridge device <NUM> may appear as the server <NUM> to the computer device <NUM>, and may appear as the computer device <NUM> to the server <NUM>. Such formatting may include modifying packet headers, address information, hostnames, domain names, or the like. Alternatively, such formatting may be performed by the endpoints <NUM>, <NUM> themselves.

As shown in <FIG>, a bridge device <NUM> may include a processor <NUM>, memory <NUM>, and communications interface <NUM> to connect to a network. The processor <NUM> may be connected to the communications interface <NUM> and the memory <NUM>. The processor <NUM> may execute instructions, which may be stored in the memory <NUM>, to implement the functionality described herein.

The processor <NUM> may include a central processing unit (CPU), a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA), and/or similar device capable of executing instructions. The processor <NUM> may cooperate with the memory <NUM>, which may include a non-transitory machine-readable medium that may be an electronic, magnetic, optical, and/or other physical storage device that encodes executable instructions. The machine-readable medium may include, for example, random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), flash memory, a storage drive, an optical disc, and/or similar.

The bridge device <NUM> may include a list of active connections <NUM>, a list of available connections <NUM>, an index <NUM> of servers <NUM> correlated to bridge devices <NUM>, encryption keys <NUM>, and data <NUM> in transit between connected servers <NUM> and computer devices <NUM>. This information may be stored in the memory <NUM>.

The list of active connections <NUM> correlates open connections with computer devices <NUM> to open connections to servers <NUM>, such as shown in the top half of <FIG>. The list of active connections <NUM> may be reference to correctly route data between a computer device <NUM> and a server <NUM>.

The list of available connections <NUM> tracks connections established in response to requests from servers <NUM>, such as shown in the bottom half of <FIG>. This list may be referenced by the bridge device <NUM> when receiving a new request from a computer device. If a connection to the requested server <NUM> is available, the bridge device <NUM> may assign it to the computer device <NUM>. When an available connection is assigned to a computer device, the available connection is removed from the list of available connections <NUM> and added to the list of active connections <NUM>. Conversely, when a computer device <NUM> stops using an active connection, then the active connection is removed from the list of active connections <NUM> and added to the list of available connections <NUM>. Alternatively, a connection that goes inactive may be closed with both the client device <NUM> and the server <NUM>. A new available connection may then be opened in response to a later request from the server <NUM>. The bridge device <NUM> may monitor connections for data transfer and determine that a connection is no longer active after a timeout has elapsed.

The list of available connections <NUM> and the list of active connections <NUM> may be the same list, such as shown in <FIG>. A database may be used to store the lists <NUM>, <NUM>.

The index <NUM> of server-bridge correlations may be used by the bridge device <NUM> to route a request from a computer device <NUM> to a bridge device <NUM> that maintains a connection to the requested server <NUM>. Examples of an index <NUM> are shown in <FIG>.

The encryption keys <NUM> may be used by the bridge device <NUM> to decrypt/encrypt data communicated between connected computer devices <NUM> and servers <NUM>. As mentioned above, the bridge device <NUM> may be configured to decrypt routing information or meta data without having access to the main data payload, which may be protected by endpoint encryption between the communicating computer device <NUM> and server <NUM>.

An example computer device <NUM> is shown in <FIG>. The computer device <NUM> may include a processor <NUM>, memory <NUM>, and communications interface <NUM>. The computer device <NUM> may further include a client application <NUM>, client connection agent <NUM>, and encryption keys <NUM>. Any of this information may be stored in the memory <NUM>.

The client application <NUM> may be a user application that is to communicate with a server <NUM>. Examples of such applications include web browsers, database interfaces, document storage/processing applications, chat/email/messaging applications, and similar.

The client connection agent <NUM> connects to a bridge device <NUM> specified by a bridge identifier <NUM>, which may also be stored in memory <NUM>. Any number of bridge identifiers <NUM> may be used to specify any number of bridge devices <NUM>. The client connection agent <NUM> is configured to receive or intercept network requests from the client application <NUM> and to direct such network requests to a bridge device <NUM>. The client connection agent <NUM> may also receive responses from the bridge device <NUM>, which acts as an intermediary for the server <NUM> that was the intended target of the request, and communicate such responses to the client application <NUM>.

The client connection agent <NUM> may be implemented as an independent program, such as a TCP/IP driver, that serves multiple different client applications <NUM>. Alternatively, the client connection agent <NUM> may be integrated with a particular client application <NUM> (e.g., a plugin or complete integration). The client connection agent <NUM> may include software, hardware, or a combination of such.

The encryption keys <NUM> may be used by the client connection agent <NUM> and/or client application <NUM> to encrypt requests, data, and/or header or routing information.

An example server <NUM> is shown in <FIG>. The server <NUM> may include a processor <NUM>, memory <NUM>, and communications interface <NUM>. The server <NUM> may further include a server application <NUM>, server connection agent <NUM>, and encryption keys <NUM>. Any of this information may be stored in the memory <NUM>.

The server application <NUM> may operate to respond to requests originating from a computer device <NUM> and handled through the bridge device <NUM>. Examples of such applications include web servers, database servers, document storage/processing servers, chat/email/messaging servers, and similar.

The server connection agent <NUM> connects to a bridge device <NUM> specified by a bridge identifier <NUM>, which may also be stored in memory <NUM>. Any number of bridge identifiers <NUM> may be used to specify any number of bridge devices <NUM>. The server connection agent <NUM> is configured to provide requests and/or data received from the bridge device <NUM> to the server application <NUM>. The server connection agent <NUM> may also receive responses from the server application <NUM> and communicate such responses to the bridge device <NUM>. The server connection agent <NUM> initiates and manages outgoing connections from the server <NUM> to the bridge device <NUM> and communicates traffic through such connections.

The server connection agent <NUM> may store and manipulate connection data <NUM> to monitor active connections to the bridge device <NUM>. Connection data <NUM> may include a list of connections with indications of recent activity. Connection data <NUM> may map a connection with the bridge device <NUM> to a server application <NUM> or session. Connection data <NUM> may store an identity or properties of a computer device <NUM> originating a request. The server connection agent <NUM> may initiate a new connection to a bridge device <NUM> when connection data <NUM> indicates that all existing connections are in use.

The server connection agent <NUM> may communicate keep-alive signals to the bridge device <NUM> to keep a connection active if, for example, further use of the connection is expected. The server connection agent <NUM> may initiate the closing of a connection if, for example, further use of the connection is not expected. The server connection agent <NUM> is different from the client connection agent <NUM> in the sense that that the client connection agent <NUM> makes requests based on user driven-events, whereas the server connection agent <NUM> monitors connection activity usage and (<NUM>) closes connections when unneeded/unused, (<NUM>) sends keep-alive signals to keep useful connections open, and/or (<NUM>) initiates new connections when all existing connections are in use. The server connection agent <NUM> is configured in this way because, in contrast to conventional servers that respond to incoming connection requests, the server <NUM> can only make outgoing connection requests.

The server connection agent <NUM> may be implemented as an independent program, such as a TCP/IP driver, that serves multiple different server applications <NUM>. Alternatively, the server connection agent <NUM> may be integrated with a particular server application <NUM> (e.g., a plugin or complete integration). The server connection agent <NUM> may include software, hardware, or a combination of such.

The encryption keys <NUM> may be used by the server connection agent <NUM> and/or server application <NUM> to encrypt data and/or header or routing information.

Claim 1:
A system comprising:
a plurality of computer devices (<NUM>) connected to a network (<NUM>), the plurality of computer devices (<NUM>) operable by a plurality of users;
a server (<NUM>) connected to the network (<NUM>), the server (<NUM>) to communicate data with the plurality of computer devices (<NUM>); and
a bridge device (<NUM>) connected to the network (<NUM>), the bridge device (<NUM>) to receive connection requests from the plurality of computer devices (<NUM>) via the network (<NUM>), the bridge device (<NUM>) further to receive connection requests from the server (<NUM>) via the network (<NUM>), the bridge device (<NUM>) further to mediate data communications between the plurality of computer devices (<NUM>) and the server (<NUM>) by communicating data through open connections made based on connection requests received from the plurality of computer devices (<NUM>) and the server (<NUM>);
characterized in that the bridge device (<NUM>) includes an index of servers to bridge devices, wherein the bridge device (<NUM>) is to use the index to determine an identifier (<NUM>) of another bridge device (<NUM>) to provide data communications between a particular computer device of the plurality of computer devices (<NUM>) and the server (<NUM>), and wherein the bridge device (<NUM>) is to communicate the identifier (<NUM>) of the other bridge device (<NUM>) to the particular computing device (<NUM>).