Method and apparatus for resource locator identifier rewrite Number:7,412,539 from the United States Patent and Trademark Office (PTO) owispatent

Title: Method and apparatus for resource locator identifier rewrite

Abstract: A method for resource locator identifier rewrite in which a network security proxy insures that a resource locator identifier of a response indicates a resource access protocol that should govern a corresponding request. A security device receives from a resource host over a non-secure hypertext transfer protocol (HTTP) session a response to a request received from a client over a secure HTTP session. The response includes a uniform resource locator (URL) that is supposed to be for a resource host, but the URL does not designate a secure resource access protocol and the resource host requires the secure resource access protocol. The URL is located in the response and modified to designate the secure resource access protocol. After modification, the response is transmitted via the secure resource access protocol session to the client.

Patent Number: 7,412,539 Issued on 08/12/2008 to Gmuender,   et al.

---

Inventors:	Gmuender; John E. (San Jose, CA), Nguyen; Huy Minh (Fountain Valley, CA), Levy; Joseph H. (Salt Lake City, UT), Massing; Michael B. (San Jose, CA), Chen; Zhong (Fremont, CA), Telehowski; David M. (Sunnyvale, CA)
Assignee:	SonicWALL, Inc. (Sunnyvale, CA)
Appl. No.:	10/331,806
Filed:	December 30, 2002

---

Related U.S. Patent Documents

---

	Application Number	Filing Date	Patent Number	Issue Date
	60434776	Dec., 2002

---

Current U.S. Class:	709/246 ; 709/203; 709/217; 709/227; 726/2; 726/26; 726/4
Current International Class:	G06F 15/16 (20060101)
Field of Search:	709/203,224-226,219,246,217,227 726/2,4,26

---

References Cited [Referenced By]

---

U.S. Patent Documents

5805803	September 1998	Birrell et al.
5835718	November 1998	Blewett
5963915	October 1999	Kirsch
6081900	June 2000	Subramaniam et al.
6098093	August 2000	Bayeh et al.
7002565	February 2006	Allen et al.
2002/0156922	October 2002	Chan et al.
2003/0046586	March 2003	Bheemarasetti et al.
2003/0051142	March 2003	Hidalgo et al.

Foreign Patent Documents

	1 083 722		Mar., 2001		EP
	WO 03/036913		May., 2003		WO

Other References

PCT/US03/41216, Oct. 18, 2004, International Search Report. cited by other . PCT/US03/41216, Apr. 5, 2005, International Preliminary Examination Report. cited by other.

Primary Examiner: Flynn; Nathan J
Assistant Examiner: Siddiqi; Mohammad
Attorney, Agent or Firm: Blakely, Sokoloff, Taylor & Zafman LLP

---

Claims

---

We claim:

1. A method in a network device comprising: determining if a resource locator identifier (RLI) in a response indicates an appropriate request governing resource access protocol, wherein the appropriate request governing resource access protocol is the resource access protocol to govern a request for a resource indicated by the RLI, wherein the appropriate request governing resource access protocol is determined from a configuration file; and rewriting the RLI to indicate the appropriate request governing resource access protocol if the RLI does not indicate the appropriate request governing resource access protocol; and preventing a client that receives the response from relying on the content length indicated in the response by effectively removing a content length field in the response, wherein effectively removing the content length field comprises modifying the content length field in the response to be unrecognizable.

2. The method of claim 1 wherein the appropriate request governing resource access protocol is a secure resource access protocol.

3. The method of claim 1 wherein the appropriate request governing resource access protocol is a non-secure resource access protocol.

4. A method in a network device comprising: modifying a response with a resource locator identifier (RLI) to indicate a first resource access protocol if the RLI indicates a second resource access protocol and the network device has been configured to insure that a request for a resource indicated by the RLI is in accordance with the first resource access protocol; effectively removing a content length field in the response, wherein effectively removing the content length field comprises modifying the content length field in the response to be unrecognizable; and transmitting the modified response to a client.

5. The method of claim 4 wherein the first resource access protocol is a secure resource access protocol and the second resource access protocol is a non-secure resource access protocol.

6. The method of claim 4 further comprising disabling persistent connection and chunked transfer encoding.

7. The method of claim 4 further comprising: preserving persistent connection and chunked transfer encoding features available to the client; and disabling chunked transfer encoding features for a resource host transmitting the response.

8. A method in a network security device comprising: receiving a response with a resource locator identifier (RLI) that indicates a first resource access protocol; determining that the first resource access protocol should not govern a request for a resource indicated by the RLI; rewriting the RLI to indicate a second resource access protocol that should govern the request; encapsulating a set of one or more fragments of the response with transport layer information; effectively removing a content length field in the response, wherein effectively removing the content length field comprises modifying the content length field in the response to be unrecognizable; and transmitting the encapsulated set of fragments to a client.

9. The method of claim 8 wherein rewriting the RLI includes adding port information to the RLI.

10. The method of claim 8 wherein the first resource access protocol is a secure resource access protocol and the second resource access protocol is a non-secure resource access protocol.

11. The method of claim 8 further comprising disabling persistent connection and chunked transfer encoding.

12. The method of claim 8 further comprising: preserving persistent connection and chunked transfer encoding features available to the client; and disabling chunked transfer encoding features for a resource host transmitting the response.

13. A machine-readable medium that provides instructions, executable by a set of one or more processors to cause said set of processors to perform operations comprising: receiving a resource response message; scanning the resource response message for a set of one or more resource locator identifiers and determining if each of the set of resource locator identifiers indicates a resource access protocol that should govern a request for their indicated resource; rewriting those of the set of resource locator identifiers that are determined to not indicate the resource access protocol that should govern a request for their indicated resource to indicate an appropriate request governing resource access protocol; and effectively removing a content length indicated in the resource response message, wherein effectively removing the content length field comprises modifying the content length field in the resource response message to be unrecognizable.

14. The machine-readable medium of claim 13 further comprising transmitting the response without scanning and rewriting if the content type of the response is not text.

15. The machine-readable medium of claim 13 further comprising transmitting the response without scanning and rewriting if the header of the response does not include a content encoding field.

16. The machine-readable medium of claim 13 wherein rewriting the set of resource locator identifiers comprises including a corresponding port.

17. The machine-readable medium of claim 13 wherein determining comprises comparing the resource host identifier of each of the set of resource locator identifiers against a configuration file that designates appropriate request governing resource access protocols for resource hosts.

18. A machine-readable medium that provides instructions, executable by a set of one or more processors to cause said set of processors to perform operations comprising: determining if a resource locator identifier (RLI) in a response indicates an appropriate request governing resource access protocol, wherein the appropriate request governing resource access protocol is the resource access protocol to govern a request for a resource indicated by the RLI, wherein the appropriate request governing resource access protocol is determined from a configuration file; and rewriting the RLI to indicate the appropriate request governing resource access protocol if the RLI does not indicate the appropriate request governing resource access protocol; and preventing a client that receives the response from relying on the content length indicated in the response by effectively removing a content length field in the response, wherein effectively removing the content length field comprises modifying the content length field in the response to be unrecognizable.

19. The machine-readable medium of claim 18 wherein the appropriate request governing resource access protocol is a secure resource access protocol.

20. The machine-readable medium of claim 18 wherein the appropriate request governing resource access protocol is a non-secure resource access protocol.

21. A machine-readable medium that provides instructions, executable by a set of one or more processors to cause said set of processors to perform operations comprising: modifying a response with a resource locator identifier (RLI) to indicate a first resource access protocol if the RLI indicates a second resource access protocol and the network device has been configured to insure that a request for a resource indicated by the RLI is in accordance with the first resource access protocol; effectively removing the content length field in the response, wherein effectively removing the content length field comprises modifying the content length field in the response to be unrecognizable; and transmitting the modified response to a client.

22. The machine-readable medium of claim 21 wherein the first resource access protocol is a secure resource access protocol and the second resource access protocol is a non-secure resource access protocol.

23. The machine-readable medium of claim 21 further comprising disabling persistent connection and chunked transfer encoding.

24. The machine-readable medium of claim 21 further comprising: preserving persistent connection and chunked transfer encoding features available to the client; and disabling chunked transfer encoding features for a resource host transmitting the response.

---

Description

---

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to the field of communication. More specifically, the invention relates to communication networks.

2. Background of the Invention

Hypertext transfer protocol (HTTP) is a resource access protocol. A resource access protocol is a defined set of rules for retrieval of resources from the Internet. A resource can be an image, a hypertext markup language (HTML) page, a Java applet, program, etc. HTTP is considered to reside at the presentation layer and/or the application layer of the OSI reference model. HTTP provides guidelines for exchanges between clients and resource hosts including request and response messages. A typical HTTP exchange includes a client requesting a resource and a resource host responding with the resource. In certain scenarios, the resource host will transmit a response that redirects the client to a different resource than the one originally requested by the client. For example, a resource host may not find a requesting client's cookie in the resource host's database, and, as a result, sends a response to the requesting client that redirects the client to a login page.

Since the exchanges between clients and resource hosts often include sensitive information, security measures are applied to certain exchanges. For security, HTTP is coupled with the Secure Sockets Layer (SSL) (also known as Transport Layer Security (TLS)). From the perspective of the OSI reference model, HTTP sits over SSL. This coupling is referred to as HTTPS. After HTTP has generated a message, HTTP passes the message to SSL, which performs security operations (e.g., encryption, hashing, etc.) on the message.

HTTP uses a uniform resource locator (URL) for retrieval of a resource. A URL is an address of a resource accessible on the Internet. A URL includes a resource access protocol identifier, a resource host identifier, a path identifier, and a resource identifier. In the URL "http://www.host.com/folder/main.html," the resource access protocol identifier is "http"; the resource host identifier is "www.host.com"; the path identifier is "folder"; and the resource identifier is "main.html."

The resource access protocol identifies HTTP as the resource access protocol to be used to retrieve the identified resource.

The resource host indicated by the resource host identifier is a resource host, or server, identified as "www.host.com." Although the resource host identifier used above is a domain name, a resource host identifier may be a network address, such as an Internet Protocol (IP) address. A resource host identifier may identify a port in addition to a resource host. For example, the following two URLs identify the same resource, but the second indicates a port: 1) http://www.host.com/main.html 2) http://www.host.com:80/main.html.

The indicated port is the appropriate port for communication with the identified resource host in accordance with the identified resource access protocol. The default port for HTTP is port 80 (the default port for HTTPS is port 443), so an HTTP message with the above example URL will be communicated to the resource host identified as "www.host.com" with the port 80.

A URL does not necessarily have to include a path identifier or a resource identifier because the resource may be in a default path and have a default name. Using the previous examples, the URL "http://www.host.com/" identifies the same resource as the previous example URLs, assuming that "folder" is the default path and that "main.html" is the default resource.

The HTTP protocol and HTTPS protocol were designed such that the response (including a redirect) to a request will use the same protocol as the request used. Thus, if the request used HTTP, then the URLs of the response will use HTTP. In contrast, if the request used HTTPS, then the URLs of the response will use HTTPS. While this works for many situations, it creates problems in certain environments.

FIG. 1 (Prior Art) is a diagram of an example redirect response retransmission. In FIG. 1, a first, second, and third columns indicate resource messages respectively transmitted and received by a client 101, a content switch 103 that performs HTTP proxy, and a server 105. A hyperlink with a URL "https://www.host.com/res1.htm" is activated at the client 101, typically a personal computer. The resource host identifier is resolved to an Internet Protocol (IP) address and an HTTPS session is opened with the content switch 103. After the HTTPS session is opened, a request message 107 with "GET res1.htm" is transmitted from the client 101 to the content switch 103. The content switch 103 receives the request 107 on port 443, decrypts the request 107, and forwards the decrypted request 107 over an HTTP session to the server 105.

The content switch 103 that performs HTTP proxy and the server 105 are typically network elements in the same local area network (LAN), which is separate from the client 101. The client 101 communicates with the LAN over a public network (e.g., the Internet). The server 105 is one of many servers in a server farm. The server 105 and the other servers in the server farm are not burdened with security measures since the owner of the server farm and content switch 103 relies on the content switch 103 for security. The content switch 103 is exposed to the outside world and protects the server farm by performing HTTP proxy. The owner has dedicated resources of the servers in the server farm, including the server 105, to serving of requests instead of performing security operations. The content switch 103 performs HTTP proxy for the servers in the server farm and determines the appropriate server for a received request. In FIG. 1A, the server 105 is the appropriate server for the request 107.

The server 105 transmits a response 111 with redirect URL "http://www.host.com/res2.htm" to the content switch 103. The content switch 103 encrypts the response 111 and transmits the encrypted response 111 back over the HTTPS session to the client 101. The client 101 receives the HTTPS response 111, decrypts the response 111, and closes the HTTPS session. Assuming the redirect URL is selected, the client 101 resolves the host name and opens an HTTP session with the content switch 103 in accordance with the resource access protocol indicated by the redirect URL. The client 101 transmits a request message 113 with "GET res2.htm" to the content switch 103.

The content switch 103 receives the request message 113 on the port 80 because the content switch is running a network service to listen for traffic received on port 80. Traffic received on port 80 is redirected. In response to the request 113, the content switch 103 generates a response message 119 that indicates a redirect URL "https://www.host.com/res2.htm". The content switch 103 transmits the response 119 back to the client 101 over the HTTP session initially opened by the client 101.

The client 101 closes the HTTP session and opens a HTTPS session with the content switch 103. The client 101 generates a request message 121, encrypts the request message 121, and transmits the encrypted request message 121 to the content switch 103.

This redirect retransmission punches a hole in the security provided by HTTPS. Since the client switches to HTTP, the data transmitted from the client is unencrypted. It is assumed that the client is transmitting sensitive information (e.g., a credit card number, passwords, bank account numbers, residential address, phone numbers, etc.) since HTTPS is typically invoked for protecting communications that will most likely include sensitive information. Due to the redirect rewrite retransmission, the client is transmitting sensitive data without encryption, which can be captured and used with ease.

In addition, the number of exchanges taking place between the client 101 and the content switch 103 illustrated in FIG. 1 are unnecessary "extra" exchanges to force the client to transmit an acceptable request, which can cause substantial impact to the content switch's performance in the real world. These extra exchanges between a content switch and thousands of sessions for thousands of clients impact performance of the content switch and introduce latency in a client's wait time for a response. Both the client machine and the content switch must process an additional message per redirect. The additional redirect may also agitate users and deter them from returning to a website.

FIG. 2 (Prior Art) is an example of a client in a protected network receiving a response message with a URL that indicates HTTPS. In FIG. 2, four columns respectively indicate a client 201, an intrusion detection system (IDS) 202, a firewall 203 with a proxy, and a server 205. The firewall 203 connects external networks to the client 201. The IDS 202 sniffs traffic transmitted and received by the client 201. The server 205 transmits a response 207 with a URL "https://www.host.com/res1.htm" to the firewall 203. The firewall 203 receives the response 207 and forwards the response 207 to the client 201 (assuming the client 201 was the requesting client). If the firewall 203 has a HTTPS session open with the server 205, then the firewall 203 decrypts the response 207 before forwarding it to the client 201. The IDS 202 analyzes the response 207. Assuming the URL in the response 207 is selected, the client 201 resolves the host name of the URL and opens a HTTPS session with the firewall 203 in accordance with the URL. If the client 151 does not support SSL (e.g., corporate entities that wish to snoop traffic with an IDS, sometimes do not enable SSL on their client machines so that their traffic can be snooped by the IDS), then the client 201 cannot request the resource. The client 201 generates a request message 209, encrypts the request 209, and transmits the request 209 to the firewall 203. Since the request 209 is encrypted, the IDS 202 must be capable of decrypting the request 209 to analyze it, allow the request to pass without analysis, or hold the request. If the IDS 202 allows the request to pass, then the firewall 203 opens a HTTPS session with the server 205 and transmits the request 209 to the server 205. Hence, the request 209 has bypassed the IDS 202.

This security architecture is typically employed in a corporate environment. A corporate entity needs to protect its systems from being infected and/or prevent access to its systems by external and/or internal malignant elements while still enabling its employees to access resource beyond its local area network. The corporate entity also needs to control the types of resources or material that enters its network at the request of its employees. Therefore, a corporate entity employs both a firewall with proxy support and an intrusion detection system to protect its network from external hacking and internal violations of its computer use policy. Unfortunately, as shown in FIG. 2, an IDS can be bypassed with encryption.

Service provides also used another mechanism with a security flaw to accommodate users. In order to avoid agitating users with error messages and increasing latency, service providers allowed a pass through for messages that were not encrypted. For this mechanism, a content switch is configured to listen for traffic on both ports 80 and 443. Traffic received on port 80 is forwarded to the corresponding servers while traffic received on port 443 is decrypted. Hence, users are not inconvenienced with error messages and increased latency, but users were possibly transmitting sensitive information without encryption.

BRIEF SUMMARY OF THE INVENTION

A method and apparatus for resource locator identifier rewrite is described. According to one aspect of the invention, a method in a network security device provides for the receipt from a resource host over a non-secure hypertext transfer protocol (HTTP) session a response to a request received from a client over a secure HTTP session. The response includes a uniform resource locator (URL) that is supposed to be for a resource host, but the URL does not designate a secure resource access protocol and the resource host requires the secure resource access protocol. The URL is located in the response and is modified to designate the secure resource access protocol. The response is transmitted via the secure resource access protocol session to the client.

These and other aspects of the present invention will be better described with reference to the Detailed Description and the accompanying Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

FIG. 1 (Prior Art) is a diagram of an example redirect response retransmission.

FIG. 2 (Prior Art) is an example of a client in a protected network receiving a response message with a URL that indicates HTTPS.

FIG. 3A is an exemplary flowchart for RLI rewrite according to one embodiment of the invention.

FIG. 3B is an exemplary diagram of forward RLI rewrite for redirect according to one embodiment of the invention.

FIG. 3C is an exemplary diagram of reverse RLI rewrite according to one embodiment of the invention.

FIG. 4A is an exemplary flowchart for processing a request for redirect resource locator identifier rewrite according to one embodiment of the invention.

FIG. 4B is an exemplary flowchart for processing a resource response for redirect resource locator identifier rewrite according to one embodiment of the invention.

FIG. 5A is an exemplary flowchart for processing a request for general resource locator identifier rewrite without persistent connection according to one embodiment of the invention.

FIG. 5B is an exemplary flowchart for processing of a resource response for general resource locator identifier rewrite without persistent connection according to one embodiment of the invention.

FIG. 6A is an exemplary flowchart for processing a resource request for general resource locator identifier rewrite with persistent connection according to one embodiment of the invention.

FIG. 6B is an exemplary flowchart for processing a resource response for general resource locator identifier rewrite with persistent connection according to one embodiment of the invention.

FIG. 6C is an exemplary flowchart continuing from FIG. 6B according to one embodiment of the invention.

FIG. 7A is an exemplary diagram illustrating processing of a request in one port mode for resource locator identifier rewrite according to one embodiment of the invention.

FIG. 7B is an exemplary diagram illustrating processing of a response in one port mode for resource locator identifier rewrite according to one embodiment of the invention.

FIG. 8A is an exemplary diagram illustrating processing of a request in in-line mode for resource locator identifier rewrite according to one embodiment of the invention.

FIG. 8B is an exemplary diagram illustrating processing of a response in in-line mode for resource locator identifier rewrite according to one embodiment of the invention.

FIG. 9A is an exemplary-flowchart for processing a request for reverse RLI rewrite according to one embodiment of the invention.

FIG. 9B is an exemplary flowchart for processing a response for reverse RLI rewrite according to one embodiment of the invention.

FIG. 10A is an exemplary diagram illustrating a reverse RLI rewrite architecture sending a request according to one embodiment of the invention.

FIG. 10B is an exemplary diagram illustrating a reverse RLI rewrite architecture receiving a response according to one embodiment of the invention.

FIG. 11A is a conceptual diagram illustrating exemplary processing of a request with reference to layers from the OSI reference model according to one embodiment of the invention.

FIG. 11B is a conceptual diagram illustrating exemplary processing of a response with reference to layers from the OSI reference model according to one embodiment of the invention.

FIG. 12 is an exemplary conceptual diagram illustrating resource locator identifier rewrite with a ring buffer according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures, standards, and techniques have not been shown in detail in order not to obscure the invention.

Methods and apparatuses for resource locator identifier rewrite are described. According to various embodiments of the invention, resource locator rewrite insures that the resource access protocol indicated by the resource locator identifiers in a response, whether in the header and/or embedded in the body of the response, is the resource access protocol that should govern a request for the resource located by that resource locator identifier. Resource locator identifier (RLI) rewrite can be applied for both forward rewrite (non-secure to secure) and reverse rewrite (secure to non-secure). Furthermore, forward RLI rewrite can be applied for rewriting RLIs in the header of a message (e.g., redirects) and/or for rewriting RLIs embedded in the body of a message.

FIGS. 3A-3C illustrate RLI rewrite for different applications. FIG. 2A illustrates a generic RLI rewrite that can be applied regardless of the scenario. FIG. 2B illustrates RLI rewrite as applied to forward redirect rewrite and FIG. 2C illustrates RLI rewrite as applied to reverse rewrite. Other scenarios, such as forward RLI rewrite with persistent connection and forward RLI rewrite without persistent connections, are described in later Figures.

FIG. 3A is an exemplary flowchart for RLI rewrite according to one embodiment of the invention. At block 321, a response with at least one RLI (e.g., a URL) is received. At block 323, a RLI is located and selected. At block 325, it is determined if the selected RLI indicates a resource access protocol desired to govern a request for the resource identified by the RLI. For example, assume the RLI is a URL that indicates HTTP and a network device (e.g., a content switch, a security offloader, a security accelerator, a firewall, etc.) that performs RLI rewrite has been configured and/or programmed so that requests for the resource identified by the URL should be governed by HTTPS. The network device will determine that the desired access protocol for the resource is HTTPS. Likewise, if the URL indicates HTTPS and the network device has been configured and/or programmed so that requests for the resource should be governed by HTTP, then the network device will determine that HTTP is the appropriate request governing resource access protocol. If it is determined that the RLI does not indicate the appropriate request governing resource access protocol, then control flows to block 327. If it is determined that the RLI indicates the appropriate request governing resource access protocol, then control flows to block 329.

At block 327, the response is transmitted.

At block 329, the response is modified to indicate the appropriate request governing resource access protocol. At block 331, it is determined if the response includes additional RLIs. If the response includes additional RLIs, then control flows back to block 333. If the response does not include additional RLIs, then control flows to block 333.

At block 333, the modified response is transmitted. In one embodiment of the invention, modifications to the response only take place at the layer of the resource access protocol (e.g., the RLI is rewritten only). In another embodiment of the invention, the modifications take place at the layer of the resource access protocol and at lower layers, which will be described in more detail herein. Alternative embodiments may perform the modification(s) in other layers.

FIG. 3B is an exemplary diagram of forward RLI rewrite for redirect according to one embodiment of the invention. In FIG. 3B, a client 301 transmits resource request message 207 over a secure resource access protocol session (e.g., a HTTPS session) to a resource locator identifier (RLI) rewrite network security proxy 303. The RLI rewrite network security proxy 303 receives the request 307 on the secure resource access protocol session and decrypts the request 307. After decrypting the request 307, the proxy 303 forwards the request 307 over a non-secure resource access protocol session to a resource host 305 that is behind the RLI rewrite network security proxy 303. The resource host 305 transmits a response 311 having a RLI that indicates a non-secure resource access protocol back over the non-secure resource access protocol session to the RLI rewrite network security proxy 303. The RLI rewrite network security proxy 303 recognizes that the RLI in the response 311 should indicate a secure resource access protocol, which will be described in more detail later. The RLI rewrite network security proxy 303 rewrites the RLI to indicate the secure resource access protocol encrypts the response 311, and transmits the encrypted response 311 with the rewritten RLI back over the secure resource access protocol session to the client 301.

The client 301 requests the resource identified by the RLI in the response 311. A request 315 is generated and transmitted over the secure resource access protocol session to the RLI rewrite network security proxy 303. Regardless of whether the RLI is a redirect or a non-redirect, the RLI rewrite network security proxy 303 does not bounce a response back to the client 301 to force the client 301 to switch session types because the client 301 is requesting in accordance with the appropriate request governing resource access protocol, due to the RLI rewrite performed by the RLI rewrite network security proxy 303 on the response 311. The RLI rewrite network security proxy 303 decrypts the request 315 and forwards the decrypted request message 315 to the resource host 305.

As can been seen from FIG. 3B, the client does not transmit a request to the RLI rewrite network security proxy that is not encrypted. Hence, there no longer is a hole in the security provided by the secure resource access protocol. That is to say, the information exchanges between a client and a resource host remain secure if so desired. Maintaining information security prevents exposure of sensitive information and protects the owners of that information. Furthermore, additional message exchanges between a client and a network security device protecting a resource host are eliminated. The elimination of the operations resulting from the additional message exchanges reduces resource consumption, improves performance of network security devices involved in the message exchanges, and provides a less time consuming experience for users requesting resources from resource hosts (i.e., resource hosts located behind network security devices). In addition, resource hosts remain secure behind network security devices without modifying applications on resource hosts and increasing their burdens.

The RLI rewrite technique illustrated in FIG. 3A can also be applied for reverse RLI rewrite, which is described with reference to FIG. 3C.

FIG. 3C is an exemplary diagram of reverse RLI rewrite according to one embodiment of the invention. In FIG. 3C, four columns respectively indicate a client 341, an IDS 342, a RLI rewrite network security proxy 343, and a resource host 345. The client 341 transmits a request message 351 over a non-secure resource access protocol session established between the client 341 and the proxy 343. An IDS 342 between sniffs data, including the request 351, transmitted from the client 341 to the proxy 343. The proxy 343 receives the request 351 on the non-secure resource access protocol session, encrypts the request 351, and transmits the request over a secure resource access protocol session to the resource host 345.

The resource host 345 generates a response message 355 that has a RLI that indicates a secure resource access protocol. The resource host transmits the response 355 over the secure resource access protocol session to the proxy 343. The proxy 343 receives the response 355 on the secure resource access protocol session, decrypts the response 355, and recognizes that the response 355 indicates a secure resource access protocol, which is not the appropriate request governing resource access protocol from the perspective of the proxy 343. Therefore, the proxy 343 rewrites the RLI to indicate a non-secure resource access protocol and forwards the decrypted response 355 with the rewritten RLI to the client 341. Since the response 355 is decrypted, the IDS 342 can analyze the response 355 without having to support decryption.

As can be seen in FIG. 3C, RLI rewrite prevents resource messages (both requests and responses) from bypassing security devices, such as an intrusion detection system, and transmitting responses with RLIs that a client cannot request because the client does not support the indicated resource access protocol.

Forward RLI Rewrite

As previously stated, RLI rewrite can be applied for RLIs in the header of a message, such as for redirect, and/or for RLIs in the body.

Header Forward RLI Rewrite

FIGS. 4A-4B are exemplary flowcharts for redirect resource locator identifier rewrite according to one embodiment of the invention. FIG. 4A is an exemplary flowchart for processing a request for redirect resource locator identifier rewrite according to one embodiment of the invention. At block 403, a resource request message from a client is received over a secure resource access protocol session. At block 405, the request is decrypted. At block 407, the decrypted request is forwarded to the appropriate resource host over a non-secure resource access protocol session.

FIG. 4B is an exemplary flowchart for processing a resource response for redirect resource locator identifier rewrite according to one embodiment of the invention. At block 411, a resource response is received from the resource host. At block 413, it is determined if the resource response is a redirect. For example, a HTTP response is a redirect response if the status in the header of the HTTP response begins with the number 3. A RLI rewrite network security proxy will scan the header of the response for the status field and determine if the status value is 3xx. If it is determined that the resource response is not a redirect, then control flows to block 423. If it is determined that the resource response is a redirect, then control flows to block 415.

At block 423, the resource response is processed (e.g., the response is encrypted, encapsulated, transmitted, etc.).

At block 415, a URL of the redirect resource response is rewritten. At block 417, the resource response is encrypted. At block 421, the resource response is transmitted to the requesting client over the secure resource access protocol session.

General Forward RLI Rewrite

The Header Forward RLI rewrite describes rewriting RLIs in the header of a message, but does not describe rewriting RLIs in the body of a message. The general forward RLI rewrite described in the following figures can be applied to rewrite RLIs in the body or in the header and body of a message. RLI rewrites made to the body of a message are relatively more complicated than RLI rewrites made to the header of a message because considerations are made for changing the size of the content in the body of a message. Various embodiments of the invention perform RLI rewrites to the body of a message differently, but two embodiments are described below. In one embodiment of the invention, general forward RLI rewrite is performed without persistent connection. In another embodiment of the invention, general forward RLI rewrite is performed with persistent connection. Although these two embodiments of the invention are illustrated with forward RLI rewrite, reverse RLI rewrite can also be performed with persistent connection and without persistent connection.

General Forward RLI Rewrite Without Persistent Connections

FIGS. 5A-5B are exemplary flowcharts for general resource locator identifier rewrite without persistent connections according to one embodiment of the invention. FIG. 5A is an exemplary flowchart for processing a request for general resource locator identifier rewrite without persistent connection according to one embodiment of the invention. At block 501, a resource request message is received over a secure resource access protocol session. At block 503, the request is decrypted. At block 505, the type of transfer encoding indicated as supported by the requesting client is determined from the resource request message. If the request indicates that non-chunked transfer encoding is supported by the client, then control flows to block 509. If the resource request indicates that chunked transfer encoding is supported by the client, then control flows to block 507.

At block 507, it is ensured that the resource request does not indicate that chunked transfer encoding is supported (e.g., if the resource request is a HTTP request, then downgrading the version indicated in the request from 1.1 to 1.0). At block 509, it is ensured that the request does not indicate that persistent connection is supported. Again using HTTP as an example, indicating that persistent connection is not supported can be done by modifying the connection parameter in the header of the HTTP request from "Keep-Alive" to "close<5 spaces>" or appending "Connection: close" to the header. At block 513, the request is communicated to a resource host over a non-secure resource access protocol session.

FIG. 5B is an exemplary flowchart for processing of a resource response for general resource locator identifier rewrite without persistent connection according to one embodiment of the invention. At block 515, a response is received. At block 517, it is determined if the content type of the resource response is text. If the content type is text, then control flows to block 521. If the content type is not text (e.g., image, audio, multipart HTTP responses, etc.), then control flows to block 519. Skipping processing of responses with non-text content type increases efficiency and performance.

At block 519, the response is communicated to the requesting client over the secure resource access protocol session.

At block 521, the type of transfer encoding indicated as supported by the resource host is determined from the response. If the response indicates that non-chunked transfer encoding is supported, then control flows to block 525. If the resource response indicates that chunked transfer encoding is supported, then control flows to block 523.

At block 523, it is ensured that the response does not indicate that chunked transfer encoding is supported. At block 525, it is ensured that the response does not indicate that persistent connection is supported. At block 526, a content length field is effectively removed from the response. For example, if the resource request is a HTTP request then the header parameter "Content-Length: xxx" is modified to "Content_Length: xxx." As shown in the above example, the content length field "Content-Length: xxx" is effectively removed by replacing the hyphen in the label of the field with an underscore such that a client receiving the response is unable to recognize the content length field. As a result, the client is prevented from using the content length indicated in the response. At block 527, the response is scanned for RLIs that do not indicate an appropriate request governing resource access protocol, and those URLs are rewritten to indicate the appropriate request governing resource access protocol. For example, assume a RLI rewrite network security proxy, which is protecting resource hosts, has a rewrite configuration file with the following entries: www.securehost.com www.resourcehost.com 9.120.*.* If the RLI rewrite network security proxy finds a RLI that identifies a resource host that matches one of the resource hosts in the rewrite configuration file and that does not indicate a secure resource access protocol (assuming the appropriate request governing resource access protocol is a secure resource access protocol), then the RLI rewrite network security proxy will rewrite that RLI to indicate the secure resource access protocol. Although the example assumes the alternative to the appropriate request governing resource access protocol is a non-secure resource access protocol, in alternative embodiments of the invention the appropriate request governing resource access protocol is a particular secure resource access protocol. In such an embodiment, a RLI may indicate a secure resource access protocol, but be rewritten because it is not the particular secure resource access protocol that is desired. In such an embodiment, the appropriate request governing resource access protocol is defined in the configuration file and not assumed as in the above example that does not indicate any resource access protocol and relies on a default appropriate request governing resource access protocol.

Control flows from block 527 to block 519.

Since the size of a response will probably change due to resource locator identifier rewrite, the size of the response will be incorrect unless recomputed by the resources access protocol match assurance proxy or the client. Modifying messages to indicate that persistent connection is not supported (or disabled) and causing the header field "Content-Length" to effectively disappear forces the client to rely on close of the session to compute the length of the response it receives.

General Forward RLI Rewrite With Persistent Connection

FIGS. 6A-6C are exemplary flowcharts for general resource locator identifier rewrite with persistent connection according to one embodiment of the invention. FIG. 6A is an exemplary flowchart for processing a resource request for general resource locator identifier rewrite with persistent connection according to one embodiment of the invention. At block 601, a resource request message is received over a secure resource access protocol session. At block 602, the request is decrypted. At block 603, the type of transfer encoding indicated as supported by the client is determined from the resource request message. If the resource request indicates support of non-chunked transfer encoding, then control flows to block 605. If the resource request indicates support of chunked transfer encoding, then control flows block 607.

At block 607, it is ensured that the request does not indicate that chunked transfer encoding is supported. At block 609, the boundaries of the request are parsed. Control flows from block 609 to block 610.

At block 605, it is ensured that the request does not indicate that persistent connection is supported. At block 610, the type of transfer encoding indicated as supported by the requesting client is stored. At block 611, the request is communicated to the appropriate resource host over a non-secure resource access protocol session.

FIG. 6B is an exemplary flowchart for processing a resource response for general resource locator identifier rewrite with persistent connection according to one embodiment of the invention. At block 613, a response is received. At block 614, it is determined if the content type of the resource response is text. If the content type of the resource response is text, then control flows to block 615. If the content type of the resource response is not text, then control flows to block 616 of FIG. 6C.

At block 615, it is determined if the response indicates a content encoding. If the response does indicate a content encoding, then control flows to block 616 of FIG. 6C. If the response does not indicate a content encoding, then control flows to block 621.

At block 621, the type of transfer encoding supported by the client is determined. This information was previously stored at block 610 of FIG. 6A. If the client supports chunked transfer encoding, then control flows to block 622. If the client supports non-chunked transfer encoding, then control flows to block 631.

At block 622, it is ensured that header of the response complies with chunked transfer encoding. At block 623, it is ensured that the body of the response complies with chunked transfer encoding. Control flows from block 623 to block 624 of FIG. 6C.

At block 631, the type of transfer encoding supported by the resource host is determined from the response. If the resource host supports chunked transfer encoding, then control flows to block 632. If the resource host supports non-chunked transfer encoding then control flows to block 633.

At block 632, it is ensured that the response does not indicate that chunked transfer encoding is supported. At block 633, it is ensured that the response does not indicate that persistent connection is supported. Control flows from block 633 to block 624 of FIG. 6C.

FIG. 6C is an exemplary flowchart continuing from FIG. 6B according to one embodiment of the invention. At block 616, the type of transfer encoding indicated as supported by the client is determined. If the client supports chunked transfer encoding, then control flows to block 617. If the client supports non-chunked transfer encoding, then control flows to block 618.

At block 617, the boundaries of the response are parsed. At block 618, the response is communicated to the requesting client over a secure resource access protocol session.

At block 624, the content length is effectively removed from the response. At block 625, the response is scanned for RLIs that do not indicate an appropriate governing resource access protocol for that particular RLI, and those RLIs are rewritten. Control flows from block 625 to block 616.

Not disabling persistent connection as described in FIGS. 6A-6C allows the client to utilize chunked transfer encoding for requests while avoiding receiving chunked transfer encoded responses from the resource host. The client and the RLI rewrite network security proxy can take advantage of the features of persistent connection without encountering problems of erroneous length values in the header of responses.

Header forward resource locator identifier rewrite and general forward resource locator identifier rewrite can be implemented independently, in combination, etc. An entity may only wish to employ resource locator identifier rewrite for redirect scenarios. Another entity may wish to employ resource locator identifier rewrite for all scenarios. With general forward resource locator identifier rewrite, the option is also available to maintain persistent connection features provided by HTTP 1.1. Furthermore, the owner of a network security device may wish to employ general forward resource locator identifier rewrite for all scenarios, or header forward resource locator identifier rewrite for redirect scenarios and general forward resource locator identifier rewrite for non-redirect scenarios.

Exemplary Forward RLI Rewrite Architectures

Various architectures can be used to implement forward RLI rewrite (be it redirect and/or general; be it persistent or non-persistent). By way of illustrations, two such architecture are described below. While two such architectures are described, it should be understood that the invention is not limited to these two exemplary architectures.

FIGS. 7A-7B are diagrams illustrating an exemplary one port mode architecture according to one embodiment of the invention. FIG. 7A is an exemplary diagram illustrating processing of a request in one port mode for resource locator identifier rewrite according to one embodiment of the invention. In FIG. 7A, a content switch 703 receives an encrypted request 711 from a network cloud 721. The encrypted request 711 may have been transmitted directly from a requesting client, from an intermediary network security device protecting the actual requesting client, etc. The content switch 703 resolves the encrypted request 711 to a rule that indicates secure messages should be passed to a RLI rewrite network security proxy 701. The proxy 701 decrypts the request 711 and forwards the decrypted request 711 back to the content switch 703. The content switch 703 then forwards the decrypted request 711 to the appropriate resource host within a server farm 705.

FIG. 7B is an exemplary diagram illustrating processing of a response in one port mode for resource locator identifier rewrite according to one embodiment of the invention. In FIG. 7B, the appropriate resource host within the server farm 705 transmits to the content switch 703 a response 707 having a RLI that indicates a non-secure resource access protocol. The content switch 703 passes the response 707 to the proxy 701. The proxy 701 rewrites the RLI to indicate a secure resource access protocol and encrypts the response 707. The proxy 701 forwards the encrypted response 707 with the rewritten RLI to the content switch 703. The content switch 703 transmits the response 707 through the network cloud 721 to the requesting client.

FIGS. 8A-8B are diagrams illustrating an exemplary in-line mode architecture according to one embodiment of the invention. FIG. 8A is an exemplary diagram illustrating processing of a request in in-line mode for resource locator identifier rewrite according to one embodiment of the invention. In FIG. 8A, a RLI rewrite network security proxy 801 receives an encrypted request 811 from a network cloud 821. As in FIG. 7A, the encrypted request 811 may have been transmitted directly from a requesting client, from an intermediary network security device protecting the requesting client, etc. The proxy 801 decrypts the request 811 and forwards the decrypted request 811 to a content switch 803. The content switch 803 determines the appropriate resource host within a server farm 805 and transmits the decrypted request 811 to that resource host.

FIG. 8B is an exemplary diagram illustrating processing of a response in in-line mode for resource locator identifier rewrite according to one embodiment of the invention. In FIG. 8B, the appropriate resource host within the server farm 805 transmits to the content switch 803 a response 807 having a RLI that indicates a non-secure resource access protocol. The content switch 803 passes the response 807 to the proxy 801. The proxy 801 rewrites the RLI in the response 807 to indicate a secure resource access protocol and encrypts the response 807. The proxy 801 transmits the encrypted response 807 with the rewritten RLI to the requesting client via the network cloud 821.

While two exemplary architectures have been described, it is understood that other architectures are within the scope of the invention.

Reverse RLI Rewrite

As with forward RLI rewrite, reverse RLI rewrite can be performed on RLIs in the header of a message and/or in the body of a message.

Header Reverse RLI Rewrite

Performing header reverse RLI rewrite is similar to performing header forward RLI rewrite as described in FIGS. 4A-4B. FIGS. 9A-9B are exemplary flowcharts for performing header reverse RLI rewrite according to one embodiment of the invention.

FIG. 9A is an exemplary flowchart for processing a request for reverse RLI rewrite according to one embodiment of the invention. At block 901, a resource request message is received via a non-secure resource access protocol session. At block 903, the request is encrypted. At block 905, the request is communicated to a resource host via a secure resource access protocol session.

FIG. 9B is an exemplary flowchart for processing a response for reverse RLI rewrite according to one embodiment of the invention. At block 909, a resource response message is received over a secure resource access protocol session. At block 911, the response is decrypted. At block 913, the response is scanned for RLIs that indicate a secure resource access protocol session and those RLIs are rewritten to indicate a non-secure resource access protocol. At block 915, the response (or fragments of the response) is encapsulated with the appropriate information. At block 917, the decrypted response is communicated to the requesting client over a non-secure resource access protocol session.

General Reverse RLI Rewrite

When performing reverse RLI rewrite on the body of a message, reverse RLI rewrite can be performed without persistent connection or with persistent connection, similar to forward RLI rewrite as described above in FIGS. 5A-5B and FIGS. 6A-6B. For general reverse RLI rewrite, at block 501 of FIG. 5A and block 601 of FIG. 6A, the secure resource access protocol session would be a non-secure resource access protocol session and at block 513 of FIG. 5A and block 611 of FIG. 6A, the non-secure resource access protocol session would be a secure resource access protocol session. In addition, when the request is communicated to the resource host as described in block 513 of FIG. 5A and block 611 of FIG. 6A, the request would be encrypted instead of decrypted. In FIGS. 5B and 6B, the response would be decrypted for general reverse RLI rewrite after blocks 515 and 613. At block 519 of FIG. 5B and block 618 of FIG. 6B, the decrypted resource response would be transmitted over a non-secure resource access protocol session to the requesting client for general reverse RLI rewrite instead of a secure resource access protocol session.

As previously stated with respect to forward RLI rewrite, header reverse resource locator identifier rewrite and general reverse resource locator identifier rewrite can be implemented independently, in combination, etc. An entity may only wish to employ resource locator identifier rewrite for redirect scenarios. Another entity may wish to employ resource locator identifier rewrite for all scenarios. With general reverse resource locator identifier rewrite, the option is also available to maintain persistent connection features provided by HTTP 1.1. Furthermore, the owner of a network security device may wish to employ general reverse resource locator identifier rewrite for all scenarios, or header reverse resource locator identifier rewrite for redirect scenarios and general resource reverse locator identifier rewrite for non-redirect scenarios.

Exemplary Reverse RLI Rewrite Architecture

FIGS. 10A-10B are diagrams illustrating an exemplary reverse RLI rewrite architecture according to one embodiment of the invention. FIG. 10A is an exemplary diagram illustrating a reverse RLI rewrite architecture sending a request according to one embodiment of the invention. In FIG. 10A, a client 1019 is protected by an intrusion detection system (IDS) 1013 and a RLI rewrite network security proxy 1005. The client 1019 is coupled with the IDS 1013. The IDS 1013 is coupled with the proxy 1005. A non-secure resource access protocol session 1009 is established between the client 1019 and the proxy 1005. The proxy 1005 has established a secure resource access protocol session 1007 with an external network element (e.g., a resource host in a different local area network) via a network cloud 1001.

The client 1019 transmits a request 1011 to the proxy 1005. As the request passes through the IDS 1013, the IDS 1013 analyzes the request. In an alternative embodiment of the invention, data does not pass through an IDS, but a security network device, such as an IDS, sniffs the line between the client 1019 and the proxy 1005. The proxy 1005 encrypts the request 1011 and transmits it to the network cloud 1001.

FIG. 10B is an exemplary diagram illustrating a reverse RLI rewrite architecture receiving a response according to one embodiment of the invention. The proxy 1005 receives an encrypted response 1003 that has a RLI indicating a secure resource access protocol. The proxy 1005 decrypts the response 1003 and rewrites the RLI in the response 1003 to indicate a non-secure resource access protocol. The proxy 1005 forwards the decrypted response 1011 with the rewritten RLI to the client 1019 through the IDS 1013. The IDS 1013 can analyze the response 1011 since it is decrypted. Since the RLI does not indicate a secure resource access protocol, a request for the resource of that RLI from the client 1019 will not be