WO2005060202A1 - Method and system for analysing and filtering https traffic in corporate networks - Google Patents

Method and system for analysing and filtering https traffic in corporate networks Download PDF

Info

Publication number
WO2005060202A1
WO2005060202A1 PCT/EP2004/052908 EP2004052908W WO2005060202A1 WO 2005060202 A1 WO2005060202 A1 WO 2005060202A1 EP 2004052908 W EP2004052908 W EP 2004052908W WO 2005060202 A1 WO2005060202 A1 WO 2005060202A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
http
traffic
https
client
server
Prior art date
Application number
PCT/EP2004/052908
Other languages
French (fr)
Inventor
Pedro Garcia Pelaez
Original Assignee
International Business Machines Corporation
Compagnie Ibm France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0823Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer

Abstract

The proxy system according to the present invention, consists of forwarding the content of the HTTPS requests in an unusual way, by automatically generating a new certificate for the requested destination server. This new certificate is faked. It is signed by a corporate internal Certificate Authority (CA). The new certificate is included in the response sent by the proxy to the client during the SSL session establishment (according to the SSL protocol, the destination server, which in this case will be the proxy server, identifies itself using a certificate). The request is then transparently forwarded to the destination server as a normal or standard HTTP Proxy server does. To prevent clients from detecting this 'man-in-the middle attack', the internal corporate Certificate Authority (CA) used to sign the 'fake' certificates, must be included in the list of Certificates Authorities recognized by the clients in the corporate network.

Description

FR92003 0036 1 METHOD AND SYSTEM FOR ANALYSING AND FILTERING HTTPS TRAFFIC IN CORPORATE NETWORKS

Technical field of the invention

The present invention is directed to computer networks and more particularly to a method, system and computer program for transparently analysing and filtering, in an Internet Protocol (IP) network, HyperText Transfer Protocol Secure (HTTPS) traffic as if it was HyperText Transfer Protocol (HTTP) traffic.

Background of the invention

Internet The Internet is a global network of computers and computers networks (the "Net"). The Internet connects computers that use a variety of different operating systems or languages, including UNIX, DOS, Windows, Macintosh, and others. To facilitate and allow the communication among these various systems and languages, the Internet uses a language referred to as TCP/IP ("Transmission Control Protocol/Internet Protocol"). TCP/IP protocol supports three basic applications on the Internet : • transmitting and receiving electronic mail, • logging into remote computers "Telnet"), and • transferring files and programs from one computer to another ("FTP" or "File Transfer Protocol").

TCP/IP

The TCP/IP protocol suite is named for two of the most important protocols: • a Transmission Control Protocol (TCP), and • an Internet Protocol (IP).

Another name for it is the Internet Protocol Suite. The more common term TCP/IP is used to refer to the entire protocol suite. The first design goal of TCP/IP is to build an interconnection of networks that provide universal communication services: an internetwork, or internet. Each physical network has its own technology dependent communication interface, in the form of a programming interface that provides basic FR92003 0036 2 communication functions running between the physical network and the user applications.

The architecture of the physical networks is hidden from the user. The second goal of

TCP/IP is to interconnect different physical networks to form what appears to the user to be one large network. TCP is a transport layer protocol providing end to end data transfer. It is responsible for providing a reliable exchange of information between 2 computer systems. Multiple applications can be supported simultaneously over one TCP connection between two computer systems.

IP is an internetwork layer protocol hiding the physical network architecture bellow it. Part of the communicating messages between computers is a routing function that ensures that messages will be correctly directed within the network to be delivered to their destination.

IP provides this routing function. An IP message is called an IP Datagram.

Application Level protocols are used on top of TCP/IP to transfer user and application data from one origin computer system to one destination computer system. Such Application Level protocols are for instance File Transfer Protocol (FTP), Telnet, Gopher, HyperText

Transfer Protocol (HTTP).

World Wide Web

With the increasing size and complexity of the Internet, tools have been developed to help find information on the network, often called navigators or navigation systems. Navigation systems that have been developed include standards such as Archie, Gopher and WAIS. The World Wide Web ("WWW" or "the Web") is a recent superior navigation system. The Web is : • an Internet-based navigation system, • an information distribution and management system for the Internet, and • a dynamic format for communicating on the Web.

The Web seamlessly, for the use, integrates format of information, including still images, text, audio and video. A user on the Web using a graphical user interface (GUI) may transparently communicate with different host computers on the system, and different system applications (including FTP and Telnet), and different information formats for files and documents including, for example, text, sound and graphics. FR92003 O036

Browser

After receipt, the Web client formats and presents the data or activates an ancillary application such a sound player to present the data. To do this, the server or the client determines the various types of data received. The Web Client is also referred to as the Web Browser, since it in fact browses documents retrieved from the Web Server.

HyterText Transfer Protocol (HTTP)

HTTP is the protocol used in most systems on the Internet to transfer Web pages. In particular, HTTP is the standard protocol for non secure access to the Web. HTTP is described in the Request For Comment (RFC) 1945 (HTTP Version 1.0) and RFC 2616 (HTTP version 1.1 ).

Each Web page that appears on client monitors of the Web, may appear as a complex document that integrates, for example, text, images, sounds and animation. Each such page may also contain hyperlinks to other Web documents so that a user at a client computer using a mouse may click on icons and may activate hyperlink jumps to a new page (which is a graphical representation of another document file) on the same or a different Web server.

A Web server is a software program on a Web host computer that answers requests from Web clients, typically over the Internet. All Web use a language or protocol to communicate with Web clients which is called HyperText Transfer Protocol ("HTTP"). All types of data can be exchanged among Web servers and clients using this protocol, including Hyper Text Markup Language ("HTML"), graphics, sound and video. HTML describes the layout, contents and hyperlinks of the documents and pages. Web clients when browsing : • convert user specified commands into HTTP requests, • connect to the appropriate Web server to get information, and • wait for a response. The response from the server can be the requested document or an error message.

After the document or an error message is returned, the connection between the Web client and the Web server is closed. First version of HTTP is a stateless protocol. That is with HTTP, there is no continuous connection between each client and each server. The Web client using HTTP receives a FR92003 0036

response as HTML data or other data. This description applies to version 1.0 of HTTP protocol, while the new version 1.1 break this barrier of stateless protocol by keeping the connection between the server and client alive under certain conditions.

HyperText Transfer Protocol Secure (HTTPS) HTTPS is the extension to the HTTP protocol used in most systems on Internet to transfer Web pages in a secure way. In particular, HTTPS is the standard protocol for secure access to the Web. HTTPS is an encapsulation of the HTTP protocol within a TLS / SSL (Transport Layer Security / Secure Sockets Layer) connection.

The primary goal of the Secure Sockets Layer (SSL) protocol is to provide a private channel between communicating applications, which ensures privacy of data, authentication of the partners, and integrity. SSL is composed of two layers : • At the lower layer, a protocol for transferring data using a variety of predefined cipher and authentication combinations, called the SSL Record Protocol. • At the upper level, a protocol for initial authentication and transfer of encryption keys, called the SSL Handshake Protocol.

An SSL session is initiated as follows : • On the client (browser) the user requests a document with a special URL that commences "https:" instead of "http:". • The client code recognizes the SSL request and establishes a connection through TCP to the SSL code on the server. • The client then initiates the SSL handshake phase, using the SSL Record Protocol as a carrier.

The SSL addresses the following security issues : • Privacy : After the symmetric key is established in the initial handshake, the messages are encrypted using this key. • Integrity : Messages contain a message authentication code (MAC) ensuring the message integrity. • Authentication : During the handshake, the client authenticates the server using an asymmetric or public key. It can also be based on certificates. SSL requires each message to be encrypted and decrypted and therefore has a high performance and resource overhead. FR92003 0036

The SSL protocol is located at the top of the transport layer. SSL is also a layered protocol itself. It simply takes the data from the application layer, reformats it and retransmits it to the transport layer. SSL handles a message as follows : • The sender performs the following tasks : • takes the message from the upper layer; • fragments the data to manageable blocks; • optionally compresses the data; • applies a Message Authentication Code (MAC); • encrypts the data; • transmits the result to the lower layer. • The receiver performs the following tasks : • takes the data from the lower layer; • decrypts; • verifies the data with the negotiated MAC key; • decompresses the data if compression was used; • reassembles the message; • transmits the message to the upper layer.

The Transport Layer Security (TLS) is the evolution of the SSL protocol and is described in RFC 2246. TLS is a secure communication protocol to be used between the application and transport layers. In particular, TLS is used to secure HTTP protocol (among others) communications.

Intranet

Some companies use the same mechanism as the Web to communicate inside their own corporation. In this case, this mechanism is called an "Intranet". These companies use the same networking/transport protocols and locally based Web servers to provide access to vast amount of corporate information in a cohesive fashion. As this data may be private to the corporation, and because the members of the company still need to have access to public Web information, to avoid that people not belonging to the company can access to this private Intranet coming from the public Internet, they protect the access to their network by using a special equipment called a Firewall. FR92003 0036 6 Firewall

A Firewall protects one or more computers with Internet connections from access by external computers connected to the Internet. A Firewall is a network configuration, usually created by hardware and software, that forms a boundary between networked computers within the Firewall from those outside the Firewall. The computers within the Firewall form a secure sub-network with internal access capabilities and shared resources not available from the outside computers.

Often, the access to both internal and external computers is controlled by a single machine, said machine comprising the Firewall. Since the computer, on which the Firewall is, directly interacts with the Internet, strict security measures against unwanted access from external computers are required.

A Firewall is commonly used to protect information such as electronic mail and data files within a physical building or organisation site. A Firewall reduces the risk of intrusion by unauthorised people from the Internet. The same security measures can limit or require special software for people inside the Firewall who wish to access information on the outside. A Firewall can be configured using "Proxies" or "Socks" to control the access to information from each side of the Firewall.

Proxy Server

A Proxy, also called Application Level Gateway, provides higher level control on the traffic between two networks in that the contents of a particular service can be monitored and filtered according to the network security policy. Therefore, for any desired application, corresponding code must be installed on the Proxy in order to manage that specific service passing through said Proxy. A Proxy acts as a server to the client and as a client to the destination server. A virtual connection is established between the client and the server. Though the Proxy seems to be transparent from the point of view of the client and the server, the Proxy is capable of monitoring and filtering any specific type of data, such as commands, before sending it to the destination. For example, an FTP (File Transfer

Protocol) server is permitted to be accessed from outside. In order to protect the server from any possible attacks the FTP Proxy in the Firewall can be configured to deny PUT and MPUT commands.

A Proxy server is an application-specific relay server that runs on the host that connects a secure and non-secure network. The purpose of a Proxy server is to control exchange of FR92003 0036 7 data between the two networks at an application level instead of an IP level. By using a Proxy server, it is possible to disable IP routing between the secure and the non-secure network for the application protocol the Proxy server is able to handle, but still be able to exchange data between the networks by relaying it in the Proxy server. In order for any client to be able to access the Proxy server, the client software must be specifically modified. In other words, the client and server software must support the proxy connection.

Compared with IP filtering, Proxies provide much more comprehensive logging based on the application data of the connections. For example, an HTTP Proxy can log the URLs (Uniform Resource Locators) visited by users. Another feature of Proxies is that they can use strong user authentication.

HTTP Proxy Server

HTTP and HTTPS Proxies are described in HTTP RFCs. A HTTP Proxy is used to: • access the Internet from an network which does not have direct access to it. • accelerating access to the Internet by caching contents.

Several other functions can be performed in the Proxy when accessing HTTP contents (virus scanning, content filtering, etc.). Many of these functions can also be performed without a Proxy Server, but it is not possible (whether using a proxy or not) to perform any filtering or scanning of HTTPS traffic in the current state of the art.

A HTTP Proxy typically runs in conjunction with Firewall software and allows an access to the Internet. The Proxy Server : • waits for a request (for example a HTTP request) from inside the Firewall, • forwards the request to the remote server outside the Firewall, • reads the response, and • sends the response back to the client.

A single computer can run multiple servers, each server connection identified with a port number. A Proxy server, like an HTTP Proxy server or a FTP Proxy server, occupies a port. Typically, a connection uses standardised port numbers for each protocol (for example, HTTP = 80 and FTP = 21 ). That is why an end user has to select a specific port number for each defined Proxy server. Web Browsers usually let the end user set the host name and port number of the Proxy servers in a customisable panel. Protocols such as HTTP, FTP, Gopher, WAIS, and Security can usually have designated Proxies. Proxies FR92003 0036 8 are generally preferred over Socks for their ability to perform caching, high-level logging, and access control, because they provide a specific connection for each network service protocol.

HTTPS Traffic Filtering There is a need in corporate network and more particularly in Intranet networks to analyze incoming traffic in order to:

• prevent viruses and malicious data from entering into the corporate network.

• filter and log contents accessible from the corporate network.

In the particular case of Web pages, there are commercial and non commercial products that analyze HTTP/FTP traffic, but at the moment there is no known solution for analyzing the HTTPS traffic on connections. The main reason is that HTTPS has been designed precisely to prevent such analysis.

A filtering of the HTTPS traffic is required by many corporations (banks, big and small companies, ...) and government and there is no real solution available at the present time to satisfy such demand.

Objects of the invention

It is an object of the present invention to analyze HTTPS traffic in corporate networks and more particularly in Intranet networks.

It is another object of the present invention to intercept and decrypt, in a first step, the HTTPS traffic on a connection and to scan and filter, in a second step, said traffic.

It is another object of the present invention to make said scanning and filtering method and system available to systems supporting HTTP traffic.

It is another object of the present invention to enable a Proxy to determine which Certificate Authorities can be considered as valid within the corporate network, regardless of the configuration of the clients (browsers) within said Intranet network. FR92003 0036

It is a further object of the present invention to transparently scan and filter HTTPS traffic without modifying the communication protocols and while preserving the security of the traffic.

Summary of the invention

The present invention as claimed in independent claims, discloses a system, method and computer program, in a proxy system connecting a secure and a non secure IP (Internet Protocol) network, for analysing and/or filtering HTTPS (HyperText Transfer Protocol Secure) traffic. The method comprises the steps of:

• receiving from a client within a secure IP network, a connection request for establishing a SSL session with a server within a non secure IP network;

• establishing a SSL session with the client; said step of establishing a SSL session comprising the step of sending to the client a fake certificate for identifying itself as the server;

• receiving HTTPS traffic from the client; • converting said HTTPS traffic into HTTP traffic.

Further embodiments of the invention are provided in the appended dependent claims.

The foregoing, together with other objects, features, and advantages of this invention can be better appreciated with reference to the following specification, claims and drawings.

Brief description of the drawings

The novel and inventive features believed characteristics of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative detailed embodiment when read in conjunction with the accompanying drawings, wherein: FR92003 0036 10

• Figure 1 shows a corporate Local Area Network (LAN) accessible from the Internet network through a system comprising a Firewall and a HTTPS Proxy server according to prior art.

• Figure 2 is a flow chart describing the method of handling HTTPS traffic according to prior art.

• Figure 3 shows a corporate Local Area Network (LAN) accessible from the Internet network through a system comprising a Firewall and a HTTPS Proxy server according to the present invention.

• Figure 4 is a flow chart describing the method of intercepting HTTPS traffic according to the present invention.

• Figure 5 shows a corporate Local Area Network (LAN) accessible from the Internet network through a system comprising a Firewall and a Chained Proxy according to the present invention.

• Figure 6 is a flow chart describing the method of intercepting HTTPS traffic using a chained Proxy according to the present invention.

Preferred embodiment of the invention

The present invention is directed to a method and system for filtering HTTPS traffic and more particularly to a method and system for translating (or converting) this traffic from HTTPS into HTTP so that said traffic can be filtered in a standard manner by already existing HTTP products.

Current proxy servers just forward the HTTPS traffic to its destination. It simply acts as a forwarder for the lower level TCP connection. Common Proxy servers cannot decrypt the data they forward. The present invention adds a new function to these Proxy servers for analysing HTTPS traffic on connections. FR92003 0036 11

The method, according to the present invention, consists, for the Proxy server, of forwarding the content of the HTTPS requests in an unusual way, by automatically generating a new certificate for the requested destination server. This new certificate is faked. It is signed by a corporate internal Certificate Authority (CA). The new certificate will be included in the response sent by the proxy to the client during the SSL session establishment (according to the SSL protocol, the destination server, which in this case will be the proxy server, always identifies itself using a certificate). The request is then transparently forwarded to the destination server as a normal or standard HTTP Proxy server does.

To prevent clients (Browsers) from detecting this "man-in-the middle attack", the internal corporate Certificate Authority (CA) used to sign the "fake" certificates, must be included in the list of CAs recognized by the clients (Browsers) located in the corporate network (said corporate network is preferably an Intranet network).

The present invention provides the following additional benefits: • Virus and malicious code in HTTPS traffic can be detected.

• HTTPS traffic and URL (Uniform Resource Locator) on connections can be scanned and filtered by the Proxy server.

• Web pages accessed from the Intranet network using HTTPS can be logged in the Proxy server. In conventional proxies the HTTPS URL is encrypted and can not be seen by the proxy.

• Only valid HTTPS requests are allowed across the Proxy server, and not any kind of traffic, as it is the case with current HTTPS Proxy servers. With conventional Proxies, once the connection is established by means of a "Connect" request, the traffic can no longer be controlled since said traffic is encrypted according to the SSL protocol. The advantage of the proposed scenario is that the Proxy server can decrypt the traffic and check whether encrypted HTTP requests are valid or not.

• Certificate Authorities (that sign the Internet Web pages accessed from the Intranet network) can be checked by the Proxy server, since the Proxy server establishes the final SSL connection to the destination server and receives the certificate of the destination server. This checking prevents the clients (Browsers) from accepting invalid Certificate Authorities (CAs) and avoids attacks against clients within the Intranet network. Such attacks may consist, for instance, in inviting an end user with low FR92003 0036 12 knowledge of HTTPS security implications, to press a button in a message in order to access a service. This message may be, for instance, a Browser alert about a self signed certificate presented by the destination server. This kind of attack is based on the following principle: the hacker misleads the "victim" to do the job that he cannot do himself.

Client authentication using Secure Sockets Layer (SSL) certificates cannot be performed with the method and system according to the present invention, as the private key of the client is not known by the Proxy server. Consequently the Proxy server cannot present the client's certificate to the destination server.

HTTPS Proxy Server according to prior art

Figure 1 shows a typical implementation of a corporate Local Area Network (LAN) (103) (Secure Internal Network) accessible from the Internet network (100) (Untrusted External Network) through a system comprising a Firewall (101 ) and a HTTP/HTTPS Proxy server (102). The Proxy server (102), also called Application Level Gateway, is physically connected to :

• the Firewall (101 ). Datagrams (all traffic) coming to and from the Internet (100) are received after having been filtered by the Firewall (101) on a IP/port basis.

• the corporate LAN network (103). As the corporate servers and clients (104) are not directly connected to the Internet network (100), it is possible to define the corporate LAN network (1O3) by a range of private IP addresses, although this is not a requirement.

The client (104) performs a "Connect" request to the HTTPS Proxy server, which establishes a TCP connection to the requested server/port (105). The HTTPS Proxy responds, then, to confirm the establishment of the TCP connection and from this time, data exchanged between the client (104) and the server (105) are simply forwarded. There is no way to analyze the HTTP traffic, as said HTTP traffic is encrypted using the SSL protocol. SSL being a layer 5 protocol, only application data (HTTP requests, in this case) is encrypted (the IP and TCP headers are not encrypted) FR92003 0036 13

Method for forwarding HTTPS traffic according to prior art

As described in Figure 2, the method of forwarding HTTPS traffic across a conventional Proxy server comprises the following steps :

• Step 201. The client (Browser) sends to the Proxy server a connection request (CONNECT request) for establishing a TCP connection with the destination server. This connection request has typically following syntax: "CONNECTwww.ibm.com:443 HTTP/1.0".

• Step 202. The Proxy server establishes a TCP connection with the destination server.

• Step 203. The Proxy server replies to the client that the TCP connection with the destination server is established. The reply has typically the following syntax: "HTTP/1.1 200 Connection established". Once the TCP connection is established, the Proxy server will just forward the traffic exchanged between the client and the destination server.

• Step 204. The client sends a SSL session request for establishing a SSL session between him and the destination server across the newly created TCP connection.

• Steps 205-206. Once the SSL session is established between the client and the destination server, the Proxy server can no longer control (scan and filter) the traffic exchanged between the client and the destination server since this traffic is encrypted using the HTTPS protocol. Typical HTTP requests have the following syntax: "GET / HTTP/1.0".

HTTPS Proxy Server according to the present invention

Figure 3 shows a corporate Local Area Network (LAN) (Secure Internal Network) (303) accessible from the Internet network (Untrusted External Network) (300) through a system comprising a Firewall (301) and a HTTPS Proxy system (302) according to the present invention. The HTTPS Proxy system (302) is physically connected to :

• a Firewall (301 ). Datagrams (all traffic) coming to and from the Internet (300) are received after having been filtered by the Firewall (301 ). FR92003 0036 14

• a corporate LAN network (303). As the corporate servers and clients (304) are not directly connected to the Internet network (300), it is possible to define the corporate LAN network (303) by a range of private IP addresses, although this is not a requirement for the present invention.

The HTTPS Proxy system (302) comprises :

• a internal corporate Certificate Authority (CA) (305) for generating "fake" certificates.

• means (306) for translating (or decrypting) HTTPS traffic into HTTP traffic without being detected as a "man in the middle" by clients (Browsers).

• a conventional HTTP Filter (307) for filtering HTTP traffic.

The HTTPS Proxy system forwards the content of HTTPS requests in an unusual way: for each connection request, a new certificate for the destination server (308), signed by a corporate internal Certificate Authority (CA) (205), is automatically generated (a certificate previously cached can also be used). Once the SSL session is established between the client (304) and the proxy using this "fake" certificate, and the client has sent the HTTP request encrypted using this SSL session, this HTTP request is then transparently forwarded to the destination server (308) in the same manner as a normal or standard HTTP Proxy server would do.

Method for filtering HTTPS traffic according to the present invention

As described in Figure 4, the method of filtering HTTPS traffic according to the present invention, comprises the following steps :

• Step 401. The client within the corporate LAN network, sends a connection request (CONNECT request) to the HTTPS Proxy system in order to access a secure (HTTPS) Web page in a destination server connected to the Internet. The CONNECT request is a HTTP command used to request the HTTPS Proxy system to establish a TCP connection to a destination server. Typically, a CONNECT request has the following syntax and comprises the following parameters : "CONNECT www.ibm.com:443 HTTP/1.0". In this particular case, the CONNECT request is sent by the client to create a TCP connection with the destination server www.ibm.com, port 443. The request FR92003 0036 15 specifies that the client can talk (can exchange information) with the Proxy using the HTTP Version 1.0 protocol.

The HTTP protocol specifies the way that Browsers interact with Proxy servers (apart from the protocol used to directly retrieve Web pages). Clients and Proxy servers always exchange information in clear text. That means that when a Browser sends a request to a Proxy server, this request is not encrypted. The way requests for HTTP and HTTPS Web pages are handled by Browsers/Proxy servers, is completely different, but both requests use methods defined in the HTTP protocol: • When a Browser wants to access a HTTP URL (Uniform Resource locator) - a HTTP Web page on a server -, it sends to the Proxy server a request (the request has typically the following syntax : "GET http://www.ibm.com/ HTTP/1.0"). The Proxy server retrieves the HTTP Web page from the server and then forwards this page to the Browser. • When a Browser wants to access an HTTPS URL, it sends a request to the Proxy server (the request has typically the following syntax: "CONNECT www.ibm.com:443 HTTP/1.0"). The Proxy server establishes first a TCP connection with the server/port and once this TCP connection is established, just forwards the data exchanged between the Browser and the destination server. This TCP connection is then used by the client to send a direct HTTPS request (a HTTPS request is a HTTP request encrypted according to the SSL protocol) to the destination server.

• Step 402. The HTTPS Proxy system tests whether or not the Proxy system cache contains a certificate for the requested connection.

• Step 403. If the cache doesn't contain any certificate for the requested connection, the HTTPS Proxy system creates a certificate for said connection (in the example, 'www.ibm.com') and forwards it for signature to an internal Certificate Authority (CA). If the cache already contains a certificate for the requested connection, the process goes on directly with step 404. FR92003 0036 16

• Step 404. The HTTPS Proxy system establishes a TCP connection and, over said TCP connection, a SSL session to the destination server connected to the Internet (a TCP connection with a SSL session over said TCP connection is also called "SSL connection").

• Step 405. The HTTPS Proxy system responds to the client that a TCP connection has been established with the destination server (i.e, the HTTPS Proxy system responds "HTTP/1.0 200 Connection Established"). The client expects this response, although this response does not need to be true at this point. Note that "200" is the HTTP code for "OK". In response to a "Proxy connect request", current Proxy servers just establish a TCP connection to the destination server and then forward the HTTPS traffic exchanged between the client and the server. In the present invention, in response to the "CONNECT request", the HTTPS Proxy system establishes a SSL connection over said TCP connection. In fact, because it knows nothing about the man-in-the-middle, the client expects the establishment of a TCP connection and the client believes that it will establish itself the SSL session with the destination server.

• Step 406. The HTTPS Proxy system : • establishes a SSL session with the client across the TCP connection already established with the client, and • identifies itself to the client as the destination server by presenting to the client during the SSL session establishment, the newly generated certificate. The client accepts this certificate provided that all the clients connected to the corporate network accept the internal Certificate Authority (CA) as a Trusted Certificate Authority.

Step 407. The client sends an HTTP request, embedded in the SSL session previously established with the HTTPS Proxy system (i.e, queries "GET / HTTP/1.0"), assuming that the HTTP request is sent to the destination server instead of the HTTPS Proxy system. FR92003 0036 17 • Step 408. The proxy receives the HTTP request from the client and sees the content of this HTTP request, as the SSL session has been established between the client and the proxy. At this point the proxy can apply acces rules per URL the same way as a HTTP proxy would do.

• Step 409. The HTTP request is sent over the SSL session established between the HTTPS Proxy system and the destination server in step (404).

• Step 410. The destination server replies with the requested information.

• Step 411. The proxy receives the HTTP response from the destination server and sees the content of this HTTP response, as the SSL session has been established between the proxy and the destination server. At this point the proxy can filter the content of the HTTP response the same way as a HTTP proxy would do.

• Step 412. The HTTPS Proxy system forwards the reply of the destination server to the client originator of the request.

The difference with the method and system according to the prior art described in Figure 2, is that the HTTPS Proxy system sees the (unencrypted) content of the secure request (407-409) and the secure response (410-412), so any HTTP filter product can be used. It is important to note that some variations in the order of the steps (in particular steps 402, 404, 405, and 406) give the same result.

Second Proxy according to the present invention Alternatively, the request can be chained in clear text to another Proxy server (i.e. a virus scanning Proxy). Figure 5 shows a corporate Local Area Network (LAN) (503) accessible from the Internet network (500) through a system comprising a Firewall (501), a Chained Proxy server (507) and a HTTPS Proxy system (502). The HTTPS Proxy system (502) according to the present invention is physically connected to : FR92003 0036 18

• the Chained Proxy (507). Datagrams (all traffic) coming to and from the Internet (500) are received by this Chained Proxy server (507) after having been filtered by the Firewall (501 ).

• a corporate LAN network (503). As the corporate servers and clients (504) are not directly connected to the Internet network (500), it is possible to define the corporate LAN network (503) by a range of private IP addresses, although this is not a requirement for the present invention.

The HTTPS Proxy system (502) comprises :

• a internal corporate Certificate Authority (CA) (505) for generating "fake" certificates. • means (506) for translating (or decrypting) HTTPS traffic into HTTP traffic without being detected by the clients (Browsers), as a "man in the middle".

The HTTPS Proxy system (502) forwards the content of HTTPS requests in an unusual way : for each connection request, a new certificate for the destination server (508), signed by a corporate internal Certificate Authority (CA) (505), is automatically generated (a certificate previously cached can also be used). The request is then transparently forwarded to the Chained Proxy (507) in the same manner as a normal or standard HTTP Proxy server would do.

Method for filtering HTTPS traffic using a second Proxy according to the present invention As shown in Figure 6, step 404 of the method previously described in Figure 4, is replaced by a non-SSL connection to the Chained Proxy server and step 408 is modified. The result is the following :

• Step 601. The client sends a connection request (CONNECT request) to the HTTPS Proxy system (502).

• Step 602. The HTTPS Proxy system (502) tests whether or not the Proxy cache contains a certificate for the requested connection. FR92003 0036 19

• Step 603. If the cache doesn't contain any certificate for the requested connection, the HTTPS Proxy system creates a certificate for the requested connection (in the example, 'www.ibm.com') and forwards this certificate for signature to an internal Certificate Authority (CA). If the cache already contains a certificate for the requested connection, the process goes on directly with step 604.

• Step 604. The HTTPS Proxy system replies to the client that a TCP connection has been established with the destination server.

• Step 604. The HTTPS Proxy system establishes a TCP (non-SSL) connection to the Chained Proxy.

• Step 605. The HTTPS Proxy system replies to the client that a TCP connection has been established with the destination server (i.e, the HTTPS Proxy system replies "HTTP/1.0 200 Connection Established"). The client expects this response, although this response does not need to be true at this point. Note that "200" is the HTTP code for "OK".

• Step 606. The HTTPS Proxy system : • establishes a SSL session with the client across the already established TCP connection with the client, and • identifies itself to the client as the destination server by presenting to the client during the SSL session establishment, the newly generated certificate. The client accepts this certificate provided that all the clients connected to the corporate network accept the internal Certificate Authority (CA) as a Trusted Certificate Authority.

• Step 607. The client sends the HTTP request, embedded in the SSL session previously established with the HTTPS Proxy system (i.e, queries "GET / HTTP/1.0"), assuming that the HTTP request is sent to the destination server instead of the HTTPS Proxy system. FR92003 0036 20

• Step 608. The HTTPS proxy system receives the HTTP request from the client and sees the content of this HTTP request, as the SSL session has been established between the client and the HTTPS proxy system. At this point the HTTPS proxy system can apply acces rules per URL the same way as a HTTP proxy would do. The HTTP request is then sent by the HTTPS Proxy system to the Chained Proxy in a standard way (i.e., the HTTPS Proxy system sends "GET https://www.ibm.com/ HTTP/1.1" to the Chained Proxy.)

• Step 609. The Chained Proxy sends a standard HTTPS request to the destination server.

• Step 610. The Chained Proxy forwards to the HTTPS Proxy system the reply received from the destination server. The Chained Proxy receives the HTTP response from the destination server and sees the content of this HTTP response, as the SSL session has been established between the Chained'Proxy and the destination server. At this point the Chained Proxy can filter the HTTP response.

• Step 611. The HTTPS proxy system receives the HTTP response from the Chained Proxy in clear text (as there is no SSL between the HTTPS proxy system and the Chained Proxy) and sees the content of this HTTP response, so it can filter the content of the HTTP response the same way as a HTTP proxy would do. The HTTPS proxy system forwards then the reply received from the Chained Proxy to the client originator of the request.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood that various changes in form and detail may be made therein without departing from the spirit, and scope of the invention.

Claims

FR92003 0036 21 C/a/fT7SWhat we claim is:
1. A method, in a proxy system connecting a secure and a non secure IP (Internet Protocol) network, for analysing and/or filtering HTTPS (HyperText Transfer Protocol Secure) traffic, said method comprising the steps of:
• receiving from a client within a secure IP network, a connection request for establishing a SSL session with a server within a non secure IP network;
• establishing a SSL session with the client; said step of establishing a SSL session comprising the step of sending to the client a fake certificate for identifying itself as the server;
• receiving HTTPS traffic from the client;
• converting said HTTPS traffic into HTTP traffic.
2. The method according to the preceding claim wherein the step of sending to the client a fake certificate for identifying itself as the server, comprises the steps of:
• generating a fake certificate for the requested connection;
• forwarding said fake certificate for signature to an internal Certificate Authority (CA).
3. The method according to the preceding claim wherein the step of sending to the client a fake certificate for identifying itself as the server, comprises the steps of:
• determining whether or not a cache comprises a fake certificate for the requested connection; • If the cache doesn't comprises any fake certificate for the requested connection: • generating a fake certificate for the requested connection; • forwarding said fake certificate for signature to an internal Certificate Authority (CA); • If the cache already comprises a fake certificate for the requested connection, • retrieving said fake certificate. FR92003 0036 22
4. The method according to any one of the preceding claims wherein the step of establishing a SSL session with the client, comprises the further step of:
• establishing a SSL (Secure Sockets Layer) connection with the server.
5. The method according to any one of the preceding claims wherein the step of receiving HTTPS traffic from the client, comprises the further steps of:
• receiving HTTPS traffic from the server;
• converting said HTTPS traffic into HTTP traffic.
6. The method according to any one of the preceding claims wherein the step of converting said HTTPS traffic into HTTP traffic, comprises the further steps of: comprising the step of:
• after analysis and/or filtering of the HTTP traffic, converting said analysed and/or filtered HTTP traffic in an analysed and/or filtered HTTPS traffic;
• forwarding said analysed and/or filtered HTTPS traffic to its destination.
7. The method according to any one of the preceding claims wherein the step of establishing a SSL (Secure Sockets Layer) connection with the server, comprises the steps of:
• establishing a TCP connection with the server;
• establishing over said TCP connection, a SSL session;
• replying to the client that a TCP connection has been established with the server.
8. The method according to any one of the preceding claims wherein the step of receiving HTTPS traffic from the client or from the server, comprises the step of:
• receiving over the SSL connection established with the client, one or a plurality of HTTPS requests intended to the server; or FR92003 0036 23 • receiving over the SSL connection established with the server, one or a plurality of HTTPS replies intended to the client.
9. The method according to any one of the preceding claims wherein :
• the HTTPS traffic comprises HTTPS requests received from the client and HTTPS 5 replies received from the server; • the HTTP traffic comprises HTTP requests received from the client and HTTP replies received from the server; • a HTTPS request is a HTTP request embedded in a SSL session; • a HTTPS reply is a HTTP reply embedded in a SSL session.
10 10. The method according to any one of preceding claims wherein the step of converting said HTTPS traffic into HTTP traffic, comprises the further step of:
• analysing and/or filtering the content of said HTTP traffic.
11. The method according to any one of claims 1 to 9 wherein the step of converting said HTTPS traffic into HTTP traffic, comprises the further steps of:
15 • sending to a conventional HTTP analyser and/or filter said HTTP traffic; • receiving from said conventional HTTP analyser and/or filter the analysed and/or filtered HTTP traffic.
12. The method according to any one of claims 1 to 3 wherein the step of establishing a SSL session with the client, comprises the further step of: 0 • establishing a TCP (Transmission Control Protocol) connection with a chained HTTP proxy; • sending HTTP traffic originated by the client and intended to the server to the chained HTTP proxy; • receiving HTTP traffic originated by the server and intended to the client from the 5 chained HTTP proxy. FR92003 0036 24
13. The method according to the preceding claim wherein the step of receiving HTTP traffic from the chained HTTP proxy, comprises the further steps of:
• converting said HTTP traffic in HTTPS traffic;
• forwarding said HTTPS traffic to the client.
14. The method according to any one of claims 12 to 13 wherein the step of sending HTTP traffic to the chained HTTP proxy, comprises the further steps of:
• converting the HTTPS traffic received from the client in HTTP traffic;
• forwarding said HTTP traffic to the chained HTTP proxy.
15. The method according to any one of claims 12 to 14 wherein the step of establishing a TCP (Transmission Control Protocol) connection with a chained HTTP proxy, comprises the further step of:
• replying to the client that a TCP connection has been established with the server.
16. The method according to any one of claims 12 to 15 wherein the step of receiving HTTPS traffic from the client, comprises the step of:
• receiving over the SSL connection established with the client, one or a plurality of HTTPS requests intended to the server.
17. The method according to any one of claims 12 to 16 wherein :
• the HTTP traffic comprises HTTP requests received from the client and HTTP replies received from the server; • a HTTPS request is a HTTP request embedded in a SSL session;
• a HTTPS reply is a HTTP reply embedded in a SSL session. FR92003 0036 25
18. The method according to any one of claims 1 2 to 17 wherein the step of converting said HTTPS traffic into HTTP traffic, comprises the further step of:
• analysing and/or filtering the content of said HTTP traffic.
19. The method according to any one of claims 1 to 17 wherein the step of converting said HTTPS traffic into HTTP traffic, comprises the further steps of:
• sending to a conventional HTTP analyser and/or filter said HTTP traffic;
• receiving from said conventional HTTP analyser and/or filter the analysed and/or filtered HTTP traffic.
20. The method according to any one of claims 12 to 18 wherein the chained HTTP proxy is a conventional HTTP proxy.
21. A Proxy system comprising means adapted for carrying out the method according to any one of the preceding claims.
22. A computer program comprising instructions for carrying out the method according to any one of claims 1 to 20 when said program is executed.
PCT/EP2004/052908 2003-12-10 2004-11-10 Method and system for analysing and filtering https traffic in corporate networks WO2005060202A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP03368110.7 2003-12-10
EP03368110 2003-12-10

Publications (1)

Publication Number Publication Date
WO2005060202A1 true true WO2005060202A1 (en) 2005-06-30

Family

ID=34684633

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/052908 WO2005060202A1 (en) 2003-12-10 2004-11-10 Method and system for analysing and filtering https traffic in corporate networks

Country Status (1)

Country Link
WO (1) WO2005060202A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1667398A1 (en) * 2004-12-02 2006-06-07 Hitachi, Ltd. Method and apparatus for encrypted end-to-end communications
EP1904931A2 (en) * 2005-08-10 2008-04-02 Riverbed Technology, Inc. Split termination for secure communication protocols
EP1986400A1 (en) * 2007-04-23 2008-10-29 Secure Computing Corporation Transparent secure socket layer
KR100898771B1 (en) * 2008-02-13 2009-05-20 (주)소만사 Method for blocking roundabout access to an internet pornographic web site by internet service provider, and computer readable recording medium therefor
US8307203B2 (en) 2008-07-14 2012-11-06 Riverbed Technology, Inc. Methods and systems for secure communications using a local certification authority
US8438628B2 (en) 2005-08-10 2013-05-07 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication
US8473620B2 (en) 2003-04-14 2013-06-25 Riverbed Technology, Inc. Interception of a cloud-based communication connection
US8478986B2 (en) 2005-08-10 2013-07-02 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions
US8700892B2 (en) 2010-03-19 2014-04-15 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US8707043B2 (en) 2009-03-03 2014-04-22 Riverbed Technology, Inc. Split termination of secure communication sessions with mutual certificate-based authentication
US8776238B2 (en) 2008-07-16 2014-07-08 International Business Machines Corporation Verifying certificate use
US8782393B1 (en) 2006-03-23 2014-07-15 F5 Networks, Inc. Accessing SSL connection data by a third-party
GB2542175A (en) * 2015-09-10 2017-03-15 Openwave Mobility Inc Intermediate network entity
WO2018026290A1 (en) * 2016-08-05 2018-02-08 Auckland Uniservices Limited Certificate revocation system
US10135792B2 (en) 2015-08-25 2018-11-20 Anchorfree Inc. Secure communications with internet-enabled devices

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030131259A1 (en) * 2002-01-10 2003-07-10 Barton Christopher Andrew Transferring data via a secure network connection
FR2840487A1 (en) * 2002-05-28 2003-12-05 Axiliance On line service protection procedure uses white, black, header and page integrity checking of HTTPS communication inside firewall

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030131259A1 (en) * 2002-01-10 2003-07-10 Barton Christopher Andrew Transferring data via a secure network connection
FR2840487A1 (en) * 2002-05-28 2003-12-05 Axiliance On line service protection procedure uses white, black, header and page integrity checking of HTTPS communication inside firewall

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8473620B2 (en) 2003-04-14 2013-06-25 Riverbed Technology, Inc. Interception of a cloud-based communication connection
US7849306B2 (en) 2004-12-02 2010-12-07 Hitachi, Ltd. Relay method of encryption communication, gateway server, and program and program memory medium of encryption communication
EP1667398A1 (en) * 2004-12-02 2006-06-07 Hitachi, Ltd. Method and apparatus for encrypted end-to-end communications
US8478986B2 (en) 2005-08-10 2013-07-02 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions
EP1904931A4 (en) * 2005-08-10 2011-07-13 Riverbed Technology Inc Split termination for secure communication protocols
US8438628B2 (en) 2005-08-10 2013-05-07 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication
EP1904931A2 (en) * 2005-08-10 2008-04-02 Riverbed Technology, Inc. Split termination for secure communication protocols
US8613071B2 (en) 2005-08-10 2013-12-17 Riverbed Technology, Inc. Split termination for secure communication protocols
US8782393B1 (en) 2006-03-23 2014-07-15 F5 Networks, Inc. Accessing SSL connection data by a third-party
US9742806B1 (en) 2006-03-23 2017-08-22 F5 Networks, Inc. Accessing SSL connection data by a third-party
EP1986400A1 (en) * 2007-04-23 2008-10-29 Secure Computing Corporation Transparent secure socket layer
US8549157B2 (en) 2007-04-23 2013-10-01 Mcafee, Inc. Transparent secure socket layer
KR100898771B1 (en) * 2008-02-13 2009-05-20 (주)소만사 Method for blocking roundabout access to an internet pornographic web site by internet service provider, and computer readable recording medium therefor
US8307203B2 (en) 2008-07-14 2012-11-06 Riverbed Technology, Inc. Methods and systems for secure communications using a local certification authority
EP2308212A4 (en) * 2008-07-14 2016-06-22 Riverbed Technology Inc Methods and systems for secure communications using a local certification authority
US8776238B2 (en) 2008-07-16 2014-07-08 International Business Machines Corporation Verifying certificate use
US8707043B2 (en) 2009-03-03 2014-04-22 Riverbed Technology, Inc. Split termination of secure communication sessions with mutual certificate-based authentication
US8700892B2 (en) 2010-03-19 2014-04-15 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US9172682B2 (en) 2010-03-19 2015-10-27 F5 Networks, Inc. Local authentication in proxy SSL tunnels using a client-side proxy agent
US9178706B1 (en) 2010-03-19 2015-11-03 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US9210131B2 (en) 2010-03-19 2015-12-08 F5 Networks, Inc. Aggressive rehandshakes on unknown session identifiers for split SSL
US9166955B2 (en) 2010-03-19 2015-10-20 F5 Networks, Inc. Proxy SSL handoff via mid-stream renegotiation
US9509663B2 (en) 2010-03-19 2016-11-29 F5 Networks, Inc. Secure distribution of session credentials from client-side to server-side traffic management devices
US9705852B2 (en) 2010-03-19 2017-07-11 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US9100370B2 (en) 2010-03-19 2015-08-04 F5 Networks, Inc. Strong SSL proxy authentication with forced SSL renegotiation against a target server
US9667601B2 (en) 2010-03-19 2017-05-30 F5 Networks, Inc. Proxy SSL handoff via mid-stream renegotiation
US9648021B2 (en) 2015-08-19 2017-05-09 Hon Hai Precision Industry Co., Ltd. HTTPS content filtering method and device
US10135792B2 (en) 2015-08-25 2018-11-20 Anchorfree Inc. Secure communications with internet-enabled devices
US10135790B2 (en) 2015-08-25 2018-11-20 Anchorfree Inc. Secure communications with internet-enabled devices
US10135791B2 (en) 2015-08-25 2018-11-20 Anchorfree Inc. Secure communications with internet-enabled devices
GB2542175A (en) * 2015-09-10 2017-03-15 Openwave Mobility Inc Intermediate network entity
WO2018026290A1 (en) * 2016-08-05 2018-02-08 Auckland Uniservices Limited Certificate revocation system

Similar Documents

Publication Publication Date Title
US7558862B1 (en) Method and apparatus for remotely controlling a computer with peer-to-peer command and data transfer
US7552323B2 (en) System, apparatuses, methods, and computer-readable media using identification data in packet communications
US8312064B1 (en) Method and apparatus for securing documents using a position dependent file system
US5550984A (en) Security system for preventing unauthorized communications between networks by translating communications received in ip protocol to non-ip protocol to remove address and routing services information
US6732105B1 (en) Secure authentication proxy architecture for a web-based wireless intranet application
US6003084A (en) Secure network proxy for connecting entities
US6442687B1 (en) System and method for secure and anonymous communications
US7441265B2 (en) Method and system for session based authorization and access control for networked application objects
US6718388B1 (en) Secured session sequencing proxy system and method therefor
US7562146B2 (en) Encapsulating protocol for session persistence and reliability
US7333990B1 (en) Dynamic reverse proxy
US7900240B2 (en) Multilayer access control security system
US7099915B1 (en) Server load balancing method and system
US20050198380A1 (en) A persistent and reliable session securely traversing network components using an encapsulating protocol
US7509490B1 (en) Method and apparatus for encrypted communications to a secure server
US6351810B2 (en) Self-contained and secured access to remote servers
US20110154477A1 (en) Dynamic content-based routing
US6532493B1 (en) Methods and apparatus for redirecting network cache traffic
US7457948B1 (en) Automated authentication handling system
US7590759B2 (en) System and method for providing remote data access and trascoding for a mobile communication device
US20040088409A1 (en) Network architecture using firewalls
US7814208B2 (en) System and method for projecting content beyond firewalls
US20090300739A1 (en) Authentication for distributed secure content management system
US6182226B1 (en) System and method for controlling interactions between networks
US20050160161A1 (en) System and method for managing a proxy request over a secure network using inherited security attributes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct app. not ent. europ. phase