Naming and accessing remote servers through a security split reverse proxy disclosed a virtual network system allowing internet clients locate a remote web server by URL and access the remote web server through a reverse proxy which split as two portions connected by at least one security connection. The virtual network system includes a Host Reverse Proxy server running on a Trusted Host Server and plurality of Remote Reverse Proxy servers each running on a remote private server; and at least one security connection is established between Host Reverse Proxy server and each Remote Reverse Proxy server using SSL or Security Tunnel.

Images(12)

Claims(32)

1. A split reverse proxy system comprising: (a) a host reverse proxy server having an address known by clients; (b) a plurality of remote reverse proxy servers each communicating with at least one web server; (c) at least one persistent connection is established between the host reverse proxy server and each remote reverse proxy server.

2. The system of claim 1 wherein the host reverse proxy server further comprises (a) a client connection threads manager accepting and processing a plurality of requests, and processing and sending a plurality of responses; (b) a host proxy connectors manager sending a plurality of request packets and accepting a plurality of response packets through each persistent connection; (c) a request multiplexer multiplexing a plurality of request data packets; and (d) a response demultiplexer demultiplexing a plurality of response packets.

3. The system of claim 2 wherein the client connection threads manager further comprises (a) a client listener receiving the requests of clients and sending the responses to the clients; (b) a plurality of client connection threads each mapping to one of the requests, accepting and analyzing the request, mapping the request to one of the remote reverse proxy, encoding the client request as a plurality of sequencing request data packets, sending the sequencing request data packets to the request multiplexer, accepting a plurality of sequencing response data packets from the response demultiplexer, decoding the sequencing response data packets to a response, analyzing the response and writing to the client listener.

4. The system of claim 2 wherein the host proxy connectors manager further comprises (a) a connector listener receiving a plurality of connection requests from the remote reverse proxy servers, establishing one persistent connection for each connection request, creating a host proxy connector, forwarding the persistent connection to the host proxy connector; (b) a plurality of host proxy connectors each accepting a plurality of request packets from the request multiplexer, sending the request packets to the persistent connection; and receiving a plurality of response packets through the persistent connection, and sending the response packets to the response demultiplexer.

5. The system of claim 2 wherein the request multiplexer multiplexes a plurality of client request data packets so as to support a plurality of simultaneous client requests for each remote reverse proxy.

6. The system of claim 2 wherein the response demultiplexer demultiplexes a plurality of response packets so as to support a plurality of simultaneous web server responses for each remote reverse proxy.

7. The system of claim 1 wherein the remote reverse proxy servers each further comprises (a) a remote proxy connectors manager accepting a plurality of request packets and sending a plurality of response packets through each persistent connection; (b) an agent threads manager processing a plurality of requests, forwarding each request to a web server, accepting a plurality of responses from web servers, processing each response; (c) a request demultiplexer demultiplexing a plurality of request packets; and (d) a response multiplex multiplexing a plurality of response data packets.

8. The system of claim 7 wherein the remote proxy connectors manager has a plurality of remote proxy connectors each sending a connection request to the host reverse proxy sever, establishing a persistence connection with the host reverse proxy server, receiving a plurality of request packets and sending a plurality of response packets through the persistence connection.

9. The system of claim 7 wherein the an agent threads manager has a plurality of agent threads each receiving a plurality of sequencing request data packets from the request demultiplexer, analyzing and decoding the sequencing request data packets as a request, mapping the request to a web server, forwarding the request to the web server, accepting a response from the web server, coding the response as a plurality of sequencing response data packets, sending the sequencing response data packets to the response multiplexer.

10. The system of claim 7 wherein the request demultiplexer demultiplexes a plurality of request packets so as to support a plurality of simultaneous requests for each web server.

11. The system of claim 7 wherein the response multiplexer multiplexes a plurality of response data packets so as to support a plurality of simultaneous responses for each web server.

12. The system of claim 1 wherein one persistent connection is established between the host reverse proxy and the remote reverse proxy server. The host reverse proxy listens connection requests and the remote reverse proxy server initials to send a connection request.

13. The system of claim 1 wherein one persistent connection is established using a Transfer Control Protocol (TCP) direct connection.

14. The system of claim 1 wherein one persistent connection is established using a SOCKS proxy connection.

15. The system of claim 1 wherein one persistent connection is established using a tunnel connection.

16. A virtual network system through a security split reverse proxy comprising: (a) a Domain Name Server (DNS) having all the entries of virtual hosting host names; (b) an account center having all the account information of remote private servers; (c) a host reverse proxy server having an address known by clients; (d) a plurality of remote reverse proxy servers each communicating with at least one web server; (e) at least one security persistent connection is established between the host reverse proxy server and each remote reverse proxy server.

17. The system of claim 16 wherein the account center is a database server including (a) an account table having account name and security configuration; (b) a host table having all host names and mapping each host names to an account name; (c) a host configuration table having the configurations of each host names; (d) a client table having clients information; and (e) a client-host table mapping each client to a host name.

18. The system of claim 16 wherein the host reverse proxy server further comprises (a) a client connection threads manager accepting and processing a plurality of requests, and processing and sending a plurality of responses; (b) a host proxy connectors manager sending a plurality of request packets and accepting a plurality of response packets through each security persistent connection; (c) a request multiplexer multiplexing a plurality of request data packets; and (d) a response demultiplexer demultiplexing a plurality of response packets.

19. The system of claim 18 wherein the client connection threads manager further comprises (a) a client listener receiving the requests of clients and sending the responses to the clients; (b) a listener security handler implementing a detection method for validating and detecting the requests; (c) a account handler retrieving account information from the account center for each request and mapping the request to an account; (d) a header security handler implementing a detection method for detecting and validating headers of the request based on the account information; (e) a client authorization handler implementing a authentication and authorization method for validating clients; (f) a content cache handler implementing a caching method for caching the response contents of web servers; (g) a content security handler implementing a detection method for scanning both the request contents of clients and the response contents of web servers; (h) a plurality of client connection threads each mapping to one of the requests, accepting and analyzing the request, mapping the request to one of the remote reverse proxy, encoding the client request as a plurality of sequencing request data packets, sending the sequencing request data packets to the request multiplexer, accepting a plurality of sequencing response data packets from the response demultiplexer, decoding the sequencing response data packets to a response, analyzing the response and writing to the client listener.

20. The system of claim 19 wherein the client connection threads each further comprises (a) a header filter processing the headers of both the requests and responses by calling the account handler, header security handler and client authorization handler; (b) a content filter processing the contents of both the requests and responses by calling the content cache handler and the content security handler; and (c) a packet processor processing a request as a plurality of sequencing request data packets and converting a plurality of sequencing response data packets as a response.

21. The system of claim 18 wherein the host proxy connectors manager further comprises (a) a connector listener receiving a plurality of connection requests from the remote reverse proxy servers, establishing one security persistent connection for each connection request, creating a host proxy connector, and forwarding the persistent connection to the host proxy connector; (b) a authorization handler implementing a authentication and authorization method for validation each connection requests of remote reverse proxy servers; (c) a plurality of host proxy connectors each accepting a plurality of request packets from the request multiplexer, sending the request packets to the security persistent connection; and receiving a plurality of response packets through the security persistent connection, and sending the response packets to the response demultiplexer.

22. The system of claim 18 wherein the request multiplexer multiplexes a plurality of client request data packets so as to support a plurality of simultaneous client requests for each remote reverse proxy.

23. The system of claim 18 wherein the response demultiplexer demultiplexes a plurality of server response packets so as to support a plurality of simultaneous web server responses for each remote reverse proxy.

24. The system of claim 16 wherein the remote reverse proxy servers each further comprises (a) a remote proxy connectors manager accepting a plurality of request packets and sending a plurality of response packets through each security persistent connection; (b) an agent threads manager processing a plurality of requests and forwarding each request to a web server; and accepting a plurality of responses from web servers and processing each responses; (c) a request demultiplexer demultiplexing a plurality of request packets; and (d) a response multiplex multiplexing a plurality of response data packets.

25. The system of claim 24 wherein the remote proxy connectors manager has a (a) a authentication and authorization method having account information of the host reverse proxy server and the remote reverse proxy server, and validating each security persistent connection; and (b) a plurality of remote proxy connectors each sending a connection request to the host reverse proxy sever, establishing a security persistence connection with the host reverse proxy server, receiving a plurality of request packets and sending a plurality of response packets through the security persistence connection.

26. The system of claim 24 wherein the an agent threads manager has a plurality of agent threads each receiving a plurality of sequencing request data packets from the request demultiplexer, analyzing and decoding the sequencing request data packets as a request, mapping the request to a web server, forwarding the request to the web server, accepting a response from the web server, coding the response as a plurality of sequencing response data packets, sending the sequencing response data packets to the response multiplexer.

27. The system of claim 24 wherein the request demultiplexer demultiplexes a plurality of request packets so as to support a plurality of simultaneous requests for each web server.

28. The system of claim 24 wherein the response multiplexer multiplexes a plurality of response data packets so as to support a plurality of simultaneous responses for each web server.

29. The system of claim 16 wherein one security persistent connection is established between the host reverse proxy and the remote reverse proxy server. The host reverse proxy listens connection requests and the remote reverse proxy server initials to send a connection request.

30. The system of claim 16 wherein one security persistent connection is established using a Secure Sockets Layer (SSL) direct connection.

31. The system of claim 16 wherein one security persistent connection is established using a SOCKS proxy with Secure Sockets Layer (SSL) connection.

32. The system of claim 16 wherein one security persistent connection is established using a Secure Sockets Layer (SSL) tunnel connection.

Today users who are away from their home or office have a need to be in communication with their private computers; also users need to share their information on their private computers and even want share information on their mobile device such as cell phone and PDA. Nokia Research Center is working on their Mobile Web Server project (http://research.nokia.com/research/projects/mobile-web-server/index.html).

[0003]

In the future, no doubt we will live in a Smart House. Remote control and monitor the house will be our part of normal life. Today web applications are replacing legacy applications, most devices in the house will have web interface for monitor and control those devices. A control center will be necessary in the house. To access the control center through public network is needed.

[0004]

Security is the most important issue for a private computer. Today most private computers stay behind various network security devices such as firewalls and NATs. Those devices may block all inbound accesses and only allow a few trusted URLs and protocols going out. A security and easy way is needed to access private computers.

[0005]

Another issue is private computers don't have domain name on public network. Usually private computers only have dynamic internal Internet Protocols (IP) addresses, they don't have public IPs and domain names. How to locate a private computer on public network becomes a question.

[0006]

The present innovation solves those issues.

SUMMARY OF THE INVENTION

[0007]

“A reverse proxy is a proxy server that is installed in the neighborhood of one or more servers. Typically, reverse proxies are utilized in front of web servers. All connections coming from the Internet addressed to one of the web servers are routed through the proxy server, which may either entirely deal with the request itself, or pass the request wholly or partially to the main web server.” and “security, encryption/SSL acceleration, load distribution, and caching static content” (http://en.wikipedia.org/wiki/Proxy_server) are reasons using reverse proxy.

[0008]

“A split proxy is essentially a pair of proxies installed across two computers. Since they are effectively two parts of the same program, they can communicate with each other in a more efficient way than they can communicate with a more standard resource or tool such as a website or browser.” Google's Web Accelerator is an example of a split proxy.

[0009]

Peter Sommerlad introduce three types of reverse proxy in his book “Reverse Proxy Patterns” (http://www.modsecurity.org/archive/ReverseProxy-book-1.pdf). “The Protection Reverse Proxy pattern shows how to protect your servers on the application protocol level at the network perimeter. An Integration Reverse Proxy allows integrating a collection of servers under a common entry point, thus hiding the network and host internals. The Front Door pattern gives guidance for single sign on and access control to a set of web applications.” The invention implements all three types proxy on one “Split Reverse Proxy”

[0010]

The invention provides a virtual network system mapping a public domain name or sub-domain name to a remote private server and protecting the remote private server.

[0011]

The virtual network system spit reverse proxy as two portions: one portion, HRP (Host Reverse Proxy) server, works as front door, protection reverse proxy and web accelerator; another portion, RRP (Remote Reverse Proxy) server, works as integration reverse proxy or a single agent. HRP and RRP connected by SSL or Security Tunnel, such as Socks SSL Tunnel, SSH Tunnel, HTTPS Tunnel and HTTP VPN Tunnel. (HTTP Tunnels Though Proxies by Daniel Alman, http://www.sans.org/rr/whitepapers/covert/1202.php)

BRIEF DESCRIPTION OF THE DRAWINGS

[0012]

FIG. 1 is a block diagram of the general structure of a possible example of embodiment of the method and systems of the invention.

[0013]

FIG. 2 is a detailed block diagram of the Host Reverse Proxy server.

[0014]

FIG. 3 is a detailed block diagram of the Remote Reverse Proxy server.

[0015]

FIG. 4A is a flow diagram showing the operation of the Host Proxy Connector when connection is established.

[0016]

FIG. 4B is a flow diagram showing the operation of the Remote Proxy Connector when connection is established.

[0017]

FIG. 5A is a flow diagram showing the operation of the Host Reverse Proxy when request is processed.

[0018]

FIG. 5B is a flow diagram showing the operation of the Host Reverse Proxy when response is processed.

[0019]

FIG. 6A is a flow diagram showing the operation of the Remote Reverse Proxy when request is processed.

[0020]

FIG. 6B is a flow diagram showing the operation of the Host Reverse Proxy when response is processed.

[0021]

FIG. 7A is a sequence diagram showing a sample operation of the Host Reverse Proxy.

[0022]

FIG. 7B is a sequence diagram showing a sample operation of the Remote Reverse Proxy.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

[0023]

The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. The invention talks only about (HTTP) web servers, it applies to other protocols like FTP, IMAP, SMTP and SIP.

[0024]

Referring now to FIG. 1, there is shown a Web Client 140 accesses a remote web server 121a, or plurality of web servers 121 sub. b1 to sub. bn. There are network security devices before the 140, the Trusted Host Server (THS) 100, the Account Center 170, the Subscription System 180, the Domain Name Server 190 and the Remote Private Server (RPS) 120a and 120b. Those network security devices are not showed on FIG. 1.

[0025]

140 usually uses a web browser typing in a URL (Uniform Resource Locator) as an address, https://tv.joe.yytao.com/recorder as an example. A URL has a protocol, host name and file (page) name. In the example, https is protocol; tv.joe.yytao.com is host name (domain or sub-domain name); and recorder is file (page) name. The web browser discovers the host name's IP address on public network through 190. The host name maps to the IP address, which the host name virtually hosts on 100. In the example, yytao.com is 100, tv.joe.yytao.com has same IP address as yytao.com's, such as 82.165.134.5.

[0026]

100 can be a computer or a computer cluster, here just said a Trusted Host Server system. The host name with account information is saved on 170 and is subscribed through 180 that details are not disclosed on the invention.

[0027]

170 is well-protected security server with a database, a LDAP or other Identity and Directory Services system.

[0028]

An account table having account name and security configurations, such as “account name”, “hashed password”, “accepted IPs”, “maximum connections number” and etc. In the example, Joe is account name; a private hashed password saved in his account; and “ip=82.12.10.0; mask=255.255.254.0” as his legal IP scope.

[0029]

A host table saves all host names and maps each host names to an account name, such as joe.yytao.com->“Joe”, tv.joe.yytao.com->“Joe”, safebox.joe.yytao.com->“Joe”. One account can have a plurality of host names.

112 establishes security persistent connections 130a with RPS 120a and 130b with RPS 120b. The connection can be established by SSL direct connection or others security connection, such as a Socks SSL Tunnel. 130a and 130b allow multiple connections established for each RPS for improving performance. The trusted certification of 100 and the authentication of RPS are required for authorization.

[0039]

120a shows one case of remote private server, the Remote Reverse Proxy (RRP) 122a system and the Web Server 121 a run on the same device, such as a computer, a mobile device or other electronic device. 122a runs as an agent, forwards request from 110 to the 121a and return response from 121a to 110.

[0040]

120b shows another case of remote private server, 122b runs as a single system on 120b. 122b accesses 121 sub. b1 to bn through Local Area Network (LAN). Under this case, 122b works as integration reverse proxy, it maps URL to target web server based on mapping rules or policies.

[0041]

Referring now to FIG. 2, before 113 accept any request from 140, a security persistent connection 130 is established; otherwise a cached content or an error as response is sent back to 140.

[0042]

FIG. 4A shows the flow of a Host Proxy Connector (HPC) 221 (FIG. 2) created. In the sample, the inventor only illustrates a simple authentication and authorization method based on username and password. There is no way to limit use any other authentication and authorization method.

[0043]

The Connector Listener 216 (FIG. 2) listens all connection requests from RRP 122 in block 400. When 216 accepts a connection request, 216 opens a SSL or Security Tunnel connection in block 402. The decision block 404 will check the connection is opened or not based on connection method used. Example SSL negotiation may be failed. If a connection can't be opened, block 420 handles error and writes a log. After the connection opened, 216 is waiting the authentication of 122. 216 gets username and password; and calls Authorization Handler 214 (FIG. 2). 214 retrieves account information from 170. The decision block 410 checks if IP address matches “accepted IPs” and current connections number equals “maximum connections number”; and compares account name and hashed password. If 410 tests result is failure, 410 can't authorize the connection, 425 handles error, logs information and sends alert to administration; if 410 passes the test, 410 authorizes the connection. In block 430, 216 calls Host Proxy Connector Factory 210 (FIG. 2) to create a new Host Proxy Connector 221 (FIG. 2) with new connection identification (CID) assigned; forwards the connection to 221; and send authorization confirmation to 122. 130 is established.

233 retrieves account information from 170 based on host name. If the account of the host name exist and is good status, passes account information to 234 and add “legal” into status; otherwise goes to decision block 507 with illegal status.

If status is unauthorized in decision block 509, goes to block 545 for authentication process; otherwise goes to block 510. The inventor doesn't disclose any authentication method in this invention. Kerberos protocol, http://web.mit.edu/kerberos/, can be used as single sign on implementation; and Basic and Digest Access Authentication, http://rfc.net/rfc2617.html, can be used as HTTP Authentication implementation.

150 waits request data packets from all client connection threads in block 524. When 150 accepts a request data packet, puts a new packet in a queue. The new packet wraps the request packet with account name, client connection thread identification, packet sequence number and data. The structure of the new packet is shown in 526. In block 528, 150 calls Host Proxy Connector Factory 210 (FIG. 2) to find one of connector of the account. The connector 221 accepts a request packet including connection thread identification, packet sequence number and data from 150 and sends the request packet out to 122 through 130. So far, 110 ends 141 processing.

[0056]

FIG. 5B shows the flow of 110 processing a response.

[0057]

221 accepts a response packet including connection thread identification, packet sequence number and data from 122 in block 550; reads TID and sequence number in the packet and calls the Host TID Manager 211 (FIG. 2). 211 checks duplication of sequence number. If the sequence number is duplicate, sets the packet as “illegal”. 221 also checks the size of the packet, if too large, sets the packet as “illegal”.

[0058]

If the response packet is illegal packet in decision block 551, 221 calls the critical error processor in block 552. The critical error processor logs the error and sends alert to administrator. If the response packet passes validation of 221; 221 sends the response packet to 160.

[0059]

160 waits response packets from all host proxy connectors. In block 553, when 160 accepts a response packet from 221, 160 decode the response packet, put the response packet in a queue. If the packet is first packet or all pre-packets of the TID have been accepted, calls 231 to find the thread with identification is TID in block 555, and sends a response data packet to 243. 243 decodes the response data packet and checks the type of data.

[0060]

If the type is LINE in decision block 556, 243 saves the data as the status line (560) of the response in block 558; otherwise goes decision block 562.

[0061]

If the type is HEADER. 243 checks if the content of the response is cacheable and “content cacheable” is set in block 564. If the content is cacheable, 243 saves CACHEABLE (566) flag.

[0062]

If the type is BODY in decision block 568, 243 forwards data to 242 in block 570. 242 calls 237 to check the safety of the content in decision block 572, if the content is not safe, goes to block 578; otherwise goes to decision block 574. If the flag of CACHEABLE is set, 242 calls 236 to cache the response in block 576. After this, goes to block 592.

[0063]

If the type is ERROR in decision block 577, 243 logs error information and builds data as response based on different error in block 578. 243 sends the data to 242, and goes to block 592.

[0064]

If the type is TRAILER in decision block 580, 243 forwards trailer headers to 242 in block 582, and goes to block 592.

[0065]

If the type is END in decision block 584, 243 sends a data with end information to 242, and goes to block 592.

122 calls the Remote Proxy Connector Factory 331 (FIG. 4B) to create the Remote Proxy Connector 340 and assigns a RID as identification in block 450. 340 opens a SSL or Security Tunnel connection to the trusted host server. 340 calls 334 to validate the host server by the certification of the trusted host server. If a connection is opened successfully in decision block 452, goes to block 454; otherwise goes to block 460 for error processing. After the connection is opened, 340 calls 334 get a authentication with account name, RRP_Name, and hashed password. 340 sends the authentication to 110. 340 waits authorization information from 110 in decision block 456. If 340 receives authorization information and the connection is authorized, goes to block 470 and the connection 130 is established; otherwise logs the error and sends alert in block 465.

[0070]

FIG. 6A shows the flow of 122 processing a client request.

[0071]

110 sends a request packet to 340 through 130 in block 532 (FIG. 5A). 340 accepts the request packet in block 600. 340 calls the Remote TID Manager 332 (FIG. 3) to check TID and sequence number. If the request packet sequence number is duplicated, 332 sets the packet as illegal packet. 340 also check size of the packet. It the size of the request packet is too large, sets the packet as illegal packet. If the request packet is illegal packet in decision block 602, goes to block 604 for critical error processing; otherwise sends the request packet to the Request Demultiplexer 350 (FIG. 3).

[0072]

350 accepts the request packet in block 606. The structure of the packet shows in block 608. 350 decodes the request packet and puts the request packet in a queue. If the request packet is first packet or all pre-packets of the TID have been accepted, 350 checks the type of data.

[0073]

If the type is LINE in decision block 610, 350 calls the Agent Thread Factory 311 (FIG. 3) in block 612.

[0074]

311 creates a new agent thread and assigned the TID as the identification of the Agent Thread 320 (FIG. 3). 350 forwards the data to 320. 320 saves the data as request line in block 614.

[0075]

If the type is not LINE, 350 calls 311 to find the 320 with identification as TID in block 616 and forwards the data to the Data Handler 321.

[0076]

321 checks the type of the data.

[0077]

If the type is HEADER in decision block 618, 321 calls the Rewrite Handler 322 (FIG. 3) to process headers in block 620. 322 sends new headers to the Request Forward 323 (FIG. 3) in block 622. 323 maps request line, new headers to a web server based on mapping rules or policies. 323 makes a new connection to the web server 121 (FIG. 3) in block 624, and sends request line and headers to 121 as request. The connection is established between 320 and 121. 320 keeps the connection in block 626.

[0078]

If the type is BODY in decision block 628, 323 sends the data to 121 through the connection 626 in block 630.

[0079]

If the type is END in decision block 632, 320 ends request phase and start waiting response in block 634 and goes to block 650 in FIG. 6B.

[0080]

FIG. 6B shows the flow of 122 processing a response.

[0081]

320 waits the status line of 121 through the connection. When the Response Handler 324 (FIG. 3) accepts the status line in block 650, checks the status code.

[0082]

If the code is 1xx in decision block 652, goes to block 654 to process continue; otherwise 324 reads headers in block 660.

There is no more useful data in the response. 320 sends END type data to 321 in block 672. 320 calls 311 to destroy 320, 311 does clean job in block 678.

[0088]

360 builds a response packet with TID, sequence number and data in block 690. The response packet structure is showed in block 692. 360 calls 331 to find a 340 and sends the packet to 340. 340 sends the response packet to 110 through 130. So far, 122 processes the response.

[0089]

The system has multiple monitoring and logging methods.

[0090]

232 (FIG. 2) monitors and logs requests, responses and the status of 240.

[0091]

212 (FIG. 2) monitors and logs the connection requests of 122, the status of 221 and packets through 130.

[0092]

333 (FIG. 3) monitors and logs the connection requests of 122, the status of 340 and packets through 130.

[0093]

312 (FIG. 3) monitors and logs the status of 320, requests to 121 and responses from 121.

[0094]

Referring now to FIG. 7A and FIG. 7B are sequence diagrams showing a simple example. A client wants to access Joe's home web application of TV recorder. Joe has subscribed an account, Joe, on a trusted server yytao.com. The account uses a sub-domain joe.yytao.com hosting on yytao.com as Joe's root account. Also Joe has hosts of tv.joe.yytao.com and safebox.joe.yytao.com. Joe's account information is saved on 170.