WO2007134082A2 - Security-preserving proxy tunnel - Google Patents

Abstract

A security-preserving proxy tunnel (500) is disposed between a client computer (100) and a trusted secure server (90). The proxy tunnel (500) operates over an insecure network, in which the connection is as secure as if it were direct, but in which techniques for improving the efficiency of network communication can be applied. Particular embodiments of the invention do not need to transmit PKI private keys over any network link or expose them in any location that is not trusted; do not require modification or special configuration of the client process; do not require any modification of secure servers; and transparently bypass communications to secure servers not explicitly chosen for proxy ing, without being able to inspect their content. The client processes (12) can be web browsers and the secure servers (90) can be secure web servers.

Description

SECURITY-PRESERVING PROXY TUNNEL

RELATED APPLICATION(S)

This application claims the benefit of U.S. Provisional Application No. 60/746,705 by Gary B. Price, filed on May 8, 2006 (Confirmation Number 5602). The entire teachings of the above application are incorporated herein by reference.

BACKGROUND

There is a large demand for secure transmission of data on the Internet. One of the most common needs is for a client computer that is considered secure to send sensitive data, such as credit card details, to a web server over an insecure network, such as the Internet, to complete a financial transaction. For the transaction to be safe, the web server is authenticated by the client, the credit card details are transmitted unchanged and unseen by any third party, and the transaction is not be subject to the possibility of repudiation. That kind of communication is referred to as a "secure communication' ' .

Most secure communication for web browsers is provided by one of the Secure Sockets Layer (SSL) implementations, including its successor Transport Layer Security (TLS). These protocols are based on Public Key Infrastructure (PKI). A PKI implementation provides for asymmetric ciphers, where the primary cryptographic material consists of a public key, which may be published without loss of security, and a private key, which is kept secret by its owner. Data encrypted using an appropriate algorithm combined with the private key may be decrypted with a corresponding algorithm combined with the public key, and vice-versa.

While the SSL standards include a provision for compression, the compression algorithm is negotiated at the beginning of the secure sessions. However, the standards do not define any compression algorithms. Consequently compression is typically not used with SSL communications. Typically, to compress the traffic it is decrypted, compressed and re-encrypted using two SSL connections: one on the client side, the other on the server side. In a man-in-the -middle proxy, each of the two SSL connections is negotiated using an SSL handshake. These SSL handshakes are referred to as the client-side handshake and the server-side handshake.

SUMMARY

Embodiments of the present invention can provide an effective means of compressing data transferred over secure communications.

Certain embodiments can provide a way to transmit secure communications across a proxy tunnel, such that:

(a) the security is functionally equivalent to that of a secure direct connection so that business methods that rely on an original level of security are unaffected;

(b) the communication can be transparently intercepted so that it can be deployed in a commercial environment without changing client processes, thereby providing administrative convenience; and

(c) the behavior of the client process during operation of the proxy tunnel remains close to its behavior without the proxy tunnel, improving end-user acceptance.

One aspect of the invention can include the transfer of public key information from a client proxy to a server proxy for the purpose of incorporating it into impersonation certificates that are subsequently sent back to the client.

Another aspect of the invention can include generation of an impersonation certificate for each trusted identity certificate at or near a server proxy, such that the impersonation certificate includes the client proxy public key information, with transfer of the impersonation certificate to the client proxy for the purpose of responding to the secure handshake of a client process.

Another aspect of the invention can include a method of the client proxy that can detect that the network address of a requested website may or may not be securely proxied. Another aspect of the invention can include the generation of impersonation certificates so that they result in a client response that is analogous to what would have resulted from a direct connection between a client process and a secure server. For example, if the identification certificate has expired, the impersonation certificate can be issued with an expiry date that has passed. Or, when the identification certificate is not trusted on the server proxy, the impersonation certificate can be issued by a Certificate Authority that is not trusted by the client process.

Another aspect of the invention can include a method by which a proxy tunnel is used to provide the chain of trust for an impersonation Certificate Authority on the client. This can be used to reduce the need for administration on the client computer.

In accordance with a particular embodiment, a secure communications system and method can operate between two remote processes running on respective computers. The system includes a proxy tunnel and a first proxy component of a man- in-the -middle proxy.

The proxy tunnel is used to exchange secure data over an unsecure medium. The unsecure medium can be a public network, such as the Internet.

The first proxy component is disposed between and in communication with the proxy tunnel and a first process. The first process can be a secure server or a client process in a client-server system.

In accordance with another particular embodiment, a secure communications system and method can operate between two remote processes running on respective computers. The system can include a proxy system and a communication link.

The proxy system can be formed between a first process and a second process, including a first proxy process, a second proxy process, and a proxy tunnel. The first proxy process can be in communication with the first process to proxy the second process, the first proxy process having a first proxy cryptography key. The second proxy process can be in communication with the second process to proxy the first process, where the second proxy process includes a security certificate using at least a portion of the first proxy cryptography key. The proxy tunnel can exchange data between the first proxy process and the second proxy process. The communications link can exchange encrypted data between the first process and the second process and can include the proxy tunnel and a secure link established between the first process and the first proxy process using the security certificate.

The proxy system can be transparent to at least one of the first process or the second process. More particularly, the first process can be a security-enabled client process and the second process is a secure server process.

In the system, the secure link can employ a shared cryptography key protocol. The cryptography key can include a private key and a public key and the security certificate can use the public key.

Furthermore, the first proxy process can detect whether the second process can be securely proxied. Based on that detection, the first proxy process can bypasses the proxy tunnel when a second process cannot be proxied.

In addition, the proxy system can include a compression module for compressing data to be transmitted through the proxy tunnel.

In accordance with yet another particular embodiment, a secure communications system and method can operate between two remote processes running on respective computers. The system can include a proxy tunnel, a first proxy process, and a communication link.

The proxy tunnel can exchange data between a first process and a remote second process. The first process can be a security-enabled client process and the second process can be a secure server process.

The first proxy process can be disposed between the first process and the proxy tunnel to proxy the second process. Furthermore, the first proxy process can have a first proxy cryptography key, and operate in communication with the first process and; and

The communications link can exchange encrypted data between the first process and the second process. The communication link can include the proxy tunnel and a secure link between the first process and the first proxy process using a security certificate generated by the second proxy process, wherein the security certificate includes at least a portion of the first proxy cryptography key. The secure link can employ a shared cryptography key protocol. The first proxy cryptography key can include a private key and a public key, wherein the security certificate uses the public key.

In addition, the first proxy process can detect whether the second process can be securely proxied. In response to that detection, the first proxy process can bypass the proxy tunnel when a second process cannot be proxied.

The first proxy process can include a compression module for compressing data to be transmitted to the second process.

In yet another particular embodiment, a secure communications system and method can operate between two remote processes running on respective computers. The system can include a first proxy process, a communications link, and an impersonation security certificate.

The first proxy process is in communication with a first process over a secure link and disposed between the first process and a proxy tunnel. The first proxy process can proxy a second process located across the proxy tunnel. More particularly, the first process can be a secure server process and the second process can be a security-enabled client process. Furthermore, the secure link can employ a shared cryptography key protocol. The first proxy process can also include a compression module for compressing data to be transmitted over the proxy tunnel.

The communications link can exchange encrypted data between the first process and the second process. More particularly, the communication link can include the proxy tunnel.

The impersonation security certificate can include at least a portion of a cryptography key received from the proxy tunnel. Specifically, the security certificate can use a public key.

In still another particular embodiment, a proxy tunnel communication system and method can operate between a client process running on a client computer and a secure server process running on a secure server computer. The system can include a client process, a proxy tunnel, and a proxy.

The client proxy process can intercept a communication stream directed to a secure server process from a client process and associate the communication stream with a client proxy cryptography key pair, which includes a client proxy private key and a client proxy public key.

The proxy tunnel can operate between the client proxy process and a server proxy process associated with the secure server process. That server proxy process can include a copy of the client proxy public key for the communication stream and a security certificate can be generated from the client proxy public key. The security certificate further includes domain name information for the secure server process.

The proxy operates between the client process and the secure server process, in which the security certificate can be used to establish a secure communication link between the client process and the client proxy.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following more detailed description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1 is a schematic block diagram illustrating the context of a prior art system-SSL connection between a client and a secure server.

FIG. 2 is a flow diagram illustrating message exchanges in a prior art SSL communication.

FIG. 3 is a schematic block diagram showing the context of a prior art system on the Internet.

FIG. 4 is a schematic block diagram illustrating a particular embodiment of security-preserving proxy tunnel.

FIG. 5 is a schematic block diagram of the client proxy and server proxy components of FIG. 4.

FIG. 6 is a schematic block flow diagram of the Interceptor module of FIG. 4 participating in a client-side SSL handshake. FIG. 7 is a schematic block flow diagram of a particular SSL Server handshake function.

FIG. 8 is a schematic block flow diagram of a particular SSL Server Data Transfer function.

FIG. 9 is a schematic block flow diagram of a particular Client Certificate Manager (FIG. 5).

FIG. 10 is a schematic block flow diagram of a particular Client Key Manager (FIG. 5).

FIG. 11 is a schematic block flow diagram of a particular Client Bypass Checker (FIG. 5).

FIG. 12 is a schematic block flow diagram of a particular Client Trust Checker (FIG. 5).

FIG. 13 is a schematic block flow diagram of a particular SSL Client handshake function.

FIG. 14 is a schematic block flow diagram of a particular SSL Client Data Transfer function.

FIG. 15 is a schematic block flow diagram of a particular Server Certificate Manager (FIG. 5).

FIG. 16 is a schematic block flow diagram of a particular Server Key Manager (FIG. 5).

FIG. 17 is a schematic block flow diagram of a particular Server Bypass Checker (FIG. 5).

FIG. 18 is a schematic block flow diagram of a particular Server Trust Checker (FIG. 5).

FIG. 19 is a schematic block flow diagram of a particular Impersonation Certificate Manager (FIG. 5).

FIG. 20 is a schematic block flow diagram of a particular Impersonation Certificate Authority (FIG. 5).

FIG. 21 is a schematic block flow diagram of a particular Error Certificate Authority (FIG. 5). FIG. 22A is a message flow diagram for messages on the client side of the system of FIG. 4.

FIG. 22B is a message flow diagram for messages on the server side of the system of FIG. 4.

FIG. 23 is a schematic block diagram illustrating message flow between components of a client proxy and a server proxy.

FIG. 24 is a schematic block diagram showing an application of the present system in the Internet context.

DETAILED DESCRIPTION

Most secure communication for web browsers is provided by one of the Secure Sockets Layer (SSL) implementations, including its successor Transport Layer Security (TLS). These protocols are based on Public Key Infrastructure (PKI) using asymmetric ciphers, where the primary cryptographic material consists of a public key and a private key. Data encrypted using an appropriate algorithm combined with the private key may be decrypted with a corresponding algorithm combined with the public key, and vice- versa.

FIG. 1 is a schematic block diagram illustrating a prior art system using an SSL connection between a client and a secure server. In this simple context, a client machine 10 runs a client process 12, which communicates with a secure server 90 using an encrypted SSL link 50. The client machine and the secure server also include a respective memory 11, 91 for storing data, including static memory such as physical disk drives and dynamic memory such as electronic storage. As shown, the client memory 11 stores a trusted certificate store 14 and a cryptography key store 16, and the server memory 91 stores a certificate store 94 and a cryptography key store 96.

All commonly used web browsers provide an implementation of HTTP over SSL, and all commonly used web servers provide a corresponding server implementation. SSL is based on the X.509v3 standardization of digital certificates by the International Telecommunications Union. The certificate stores 14, 94 store digital certificates, which are used to encapsulate a public key from the key stores 16, 96. The digital certificates are signed by its issuer. Digital certificates are combined with the use of trusted third parties for representing identity. To do that, a generic digital certificate combines:

(a) a subject name that represents the identified entity, which can, for example, include a domain name to identify a secure server;

(b) an issuer name, which is a name representing the entity that issued the certificate to the entity identified by the subject name;

(c) a date range for which the certificate is valid;

(d) a public key, together with information that defines the algorithms and parameters with which it can be used;

(e) possibly additional data, which may include a domain name to identify a secure server in a more specific way than can be done in the subject name; and

(f) a digital signature of the above data. A digital signature is a PKI construct that authenticates both the origin and the content of a message in a manner that is provable to a disinterested third party. In relevant applications the signature is made up of information that defines the algorithm being used together with an encrypted hash of the message, the hash encryption being done with the signer's private key. The signature may be verified using the signer's public key.

A certificate infrastructure uses certificates to formalize trust relationships by allowing the trustworthiness of a certificate that represents an identity to be determined by checking its signature, the signature of its issuer's certificate and so on back to a root certificate that is trusted.

In typical implementations, one or more trusted root certificates are kept in the trusted store 14 on a computer. Population of the trusted store 14 is performed by a secure process out-of-band with respect to the SSL communications. Usually the contents of the trusted store 14 are set when the operating system, or possibly a web browser is installed. Subsequently, the addition of certificates to the trusted store 14, or their removal from it can be done only with the explicit cooperation of the end-user. In one common implementation this is done by providing a pop-up dialog box that asks the end user if they wish to accept the certificate into their trusted store 14. There can be additional stores of intermediate certificates on the machine and accompanying the certificate of interest. Certificates from both kinds of store can be used in establishing a chain of trust back to the root certificate. In particular, in SSL communications it is common to supply a certificate chain rather than a single certificate to establish identity. Trust in the end certificate of the chain, which carries the identification information, is established by following the chain back to a trusted root certificate that is already in the trusted store. When a secure server supplies a certificate chain that terminates in an identification certificate, it is referred to as an identification certificate chain, which includes the case when a single certificate (a chain of length 1) is supplied.

FIG. 2 is a flow diagram illustrating message exchanges in a prior art SSL communication. The communication is typically initiated when an end user enters a domain name, such as in a Universal Resource Locator (URL) into a Client Process 12. As shown, the Client Process 12 communicates with a Secure Server 90 using an SSL link 50. An SSL connection is divided into handshake 5OH and data transfer 5OD phases. The handshake phase 5OH authenticates the secure server and establishes the cryptographic keys that are used to protect the data to be transmitted. The handshake is completed before any data is transmitted. Once the handshake is completed, the data is transmitted as a series of records that are protected by encryption using the cryptographic keys.

Again, the first phase to take place is the handshake 5OH between the Client Process 12 and the Secure Server 90. The handshake begins with a Client HELLO message 51 being sent from the Client Process 12 to the Secure Sever 90. As understood, by those of ordinary skill in the art, that client HELLO request 51 can include various data, such as an indication of the protocol version used by the client, a list of supported ciphers, a list of compression methods supported by the client, a random number generated by the client, a session identifier, and a direct-to- server Internet Protocol (IP) address.

Because the initial client request does not contain the domain name of the secure server, there is difficulty in attempting to provide a transparent proxy for SSL, because it implies that the domain name check is done by the client process. In some implementations it may be convenient to intercept the client communication stream by using the SSL CONNECT method, in which the requested domain name is transmitted to a client proxy. However this is not universally desired and is not assumed by the present system.

The initial client request 51 is received by the Secure Server 90, which chooses a cipher and compression method and responds to the Client Process 12 with data 52 that identifies the protocol version, the chosen cipher, the chosen compression method, a random number, a session identifier, and an identification certificate chain. The Secure Server 90 identifies itself by supplying the identification certificate chain in the return handshake message 52.

The return handshake message 52 is received by the Client Process 12, which then verifies the certificate trust, and the server domain name. Verification of the trustworthiness of the identification certificate is based on local data on the client machine 10, including a certificate in the trusted store 14 (FIG. 1), and the remainder of the identification certificate chain (excluding the root of the chain, if that is self-signed).

After verification, the Client Process 12 extracts the server public key and generates a pre -master secret 53, which is transmitted to the Secure Server 90. The Client Process 12 then computes and transmits a handshake Message Authentication Code (MAC) 54 to the Secure Server 90. The Secure Server 90 decrypts the pre -master secret with the server private key.

Both the Client Process 12 and the Secure Server 90 next compute an encryption key, a MAC key, and a handshake MAC. The MAC of all handshake messages is then exchanged in respective messages 54, 55. The result is a secure data connection 56.

The second phase is data transfer 5OD, in which the Client Process 12 and the Secure Server 90 operates as a request -response pair over the secure data connection 56. The Client Process 12 sends requests to the Secure Server 90 over the secure data connection 56. The Secure Server 90 then sends response messages to the requests back to the Client Process 12 over the same connection 56. The data transfer over that same secure connection 56 can be repeated for addition requests 57 and responses 58.

Secure communication systems have various application. One common application is an Internet based application, where an end user enters a URL into a web browser. If that URL is on a secure server, the browser and secure server can negotiate a secure session using SSL.

FIG. 3 is a schematic block diagram showing the context of a prior art system on the Internet. As shown, multiple client machines 10-1, 10-2 access the secure servers of an enterprise 80 via the Internet 5. A plurality of secure servers 90-1, 90-2, 90-3 in the enterprise 80 can operate on a enterprise network 82 behind a firewall 84. As shown, each client machine 10-1, 10-2 runs many client processes 12-1, 12-2, 12-3, 12-4, 12-5, 12-6. There may be additional client machines and each client machine can also run many client processes.

There can also be many communication streams from any client process, as indicated by communication streams si, s2 from client process 12-1, communication streams s3 and s4 from client process 12-5 and communication streams s5, s6 from client process 12-6. The communication streams may be directed towards any of the secure servers in the Enterprise 80, or to secure servers outside the Enterprise 80, such as secure servers 90-4, 90-5.

While the secure communication streams are encrypted, they are essentially incompressible, independent of the compressibility of the content being transferred. Typically, to compress the traffic it is decrypted, compressed and re-encrypted using two SSL connections: one on the client side, the other on the server side. The encryption of the SSL connection on the client side uses a PKI key pair for which the private key is known to the client proxy. The public key from the key pair is supplied to the client process in an impersonation certificate that plays the part of the identification certificate of the web server. This arrangement is known as a man-in-the- middle proxy.

In the man-in-the -middle proxy, each of the two SSL connections is negotiated using the SSL handshake. These SSL handshakes are referred to as the client- side handshake and the server- side handshake.

A proxy tunnel is a system that intercepts a bidirectional stream of communication from a client process to a server process without modification of the client process (possibly using additional software installed on the client machine) and without modification of the server process and server machine. A proxy tunnel makes it possible for client-server communication to take advantage of data processing in the tunnel. The data processing may include, without limitation, data inspection, data compression, client-end and server-end caching, increased security, and network transport protocol optimization.

For the proxy tunnel to be useful in typical applications, the work processes of an end-user using the client process should be largely unaffected by the existence of the proxy tunnel. One aspect of this requirement is that either the client process is able to direct its communications streams to the client proxy, or they are transparently intercepted. Another aspect is that conditions that are detected at the server end of the tunnel are propagated to the client end so that the client can respond substantially as it would have done in the absence of the transparent proxy tunnel.

It is understood that a single server proxy can be used to process the communications of multiple client proxies. A server proxy process can communicate with a secure server via a HTTPS proxy by using the HTTP "CONNECT" method. A single client proxy process can operate on a client machine and can intercept communications from multiple processes operating on that machine. A single client proxy process can operate on a gateway machine and can intercept communications from multiple processes operating on multiple client machines. Furthermore, instead of a single server proxy, there can be a farm of server proxies that the client proxy sees as if it were a single server proxy.

Each client process can participate in a plurality communication streams meant for remote content servers. Each such communication stream can be intercepted and give rise to a corresponding communication stream across the proxy tunnel. The communication within the proxy tunnel can be kept secure by well known methods, including an SSL connection.

The easiest place to locate a Certificate Authority (CA) for a man-in-the -middle proxy is near the client, but that location is not secure, as a single successful attack might obtain the private key of the Certificate Authority and thereby compromise all future secure communications. A better location for the Certificate Authority is desired.

Transparent interception of network traffic by proxies minimizes system administration and the impact on business processes. However, the domain name requested by the SSL client is not available from transparent interception. This means that the domain name supplied by the secure server in its identification certificate cannot be checked by any component in the proxy tunnel, and so the domain name is passed to the client process for checking. Secure servers can include the domain name in an identification certificate in a number of forms, such as in the subject name or in the dNSName extension. It is anticipated that an application can use a custom attribute or some other mechanism to include the domain name in the certificate in a way not understood by any other application. A way of reliably providing the domain name of the secure server to the client process, independent of how it is represented in its identification certificate is sought.

Optimally, the proxy tunnel should not change the behavior of the client process in any important way. For example, if the client process would not have silently accepted the identification certificate, it should also not silently accept the impersonation certificate, and the notification, if any, displayed to the end user in both cases should be similar. Not doing this would prevent end-users accepting communication from some secure servers because of trivial certificate problems. It might also allow end-users to accept impersonation certificates for which they would reject the corresponding identification certificates. A way of ensuring the client behavior retains fidelity to its unproxied behavior is sought.

An end user may access a variety of secure servers. For some of these it may be desired not to proxy the communication. For example, an enterprise might wish to restrict the use of its server proxy to proxying secure communications to its own servers. One reason for doing this could be that the enterprise does not want encrypted data that is directed towards secure servers for which it has no responsibility to appear in plain text within its server proxy. A system for proxying secure communications that includes a centralized mechanism for restricting the secure servers that may be proxied is sought.

Most enterprises use a two-level certificate infrastructure. In this arrangement, a well-known root certification authority certifies an intermediate certificate authority owned by the enterprise, and then that enterprise Certificate Authority is used to issue certificates for the secure servers in the enterprise. It is common to regularly update the intermediate Certificate Authority certificate. In that case the impersonation Certificate Authority needs a new Certificate Authority certificate, and this needs to be issued to the client machine to enable that machine to maintain trust in the impersonation CA. A way of minimizing this kind of certificate infrastructure maintenance is sought.

FIG. 4 is a schematic block diagram illustrating a particular embodiment of security-preserving proxy tunnel. As shown, a Client Machine 100 can be physically identical to the client machine 10 (FIG. 1) and includes a Client Process 12 (FIG. 1) and a Client Proxy Process 102. A Server Proxy Machine 700 is disposed between the Secure Server 90 and the Client Machine 100 and includes a Server Proxy Process 702. Communication is no longer directly between the Client Machine 100 and the Secure Server 90, but now goes via a proxy tunnel transport link 520 with endpoints at the Client Proxy Process 102 and the Server Proxy Process 702.

As shown, the client and server sides include memory. In particular, the Client Process 12 and the Client Proxy Process 102 access memory 101, which includes the Trusted Certificate Store 14 and Client Process Cryptography Keys 16 (FIG. 1), and Cryptography Keys 116 associated with the Client Proxy Process 102. On the server side, the Secure Proxy Machine 700 includes memory 701 for storing a Certificate Store 714 and Cryptography Keys 716 associated with the Server Proxy Process 702.

During operation, the Client Process 12 attempts to make an SSL connection to the Secure Server 90. Its encrypted communication stream TCl is intercepted transparently by an Interceptor Module 110.

The Interceptor 110 can allow an SSL communication stream TCl to be proxied by directing it towards an SSL Server 120, or it can bypass the SSL Server 120 over a bypass link transport TCB. The decision whether or not to bypass can be made on the basis of information obtained on the client and possibly on the server proxy machine, using the network address that is supplied in the client HELLO. Possible mechanisms for bypass can include forwarding the communication through the proxy transport link 520 and forwarding the communication directly to the Secure Server 90. The former is illustrated by communication streams TCB, TSB. Bypass by either technique can use standard techniques. Provision of the bypass decision and bypass mechanism addresses concerns regarding a user accessing a variety of servers discussed above. The mechanism by which the bypass decision is made uses Auxiliary Client Components 106 over unencrypted link TC7, as described below.

When the SSL communication is to be proxied rather than transparently forwarded, the SSL client HELLO is forwarded to the local SSL server 120. The SSL server 120 negotiates an SSL connection with the client process 12 using a method that involves data from the Auxiliary Client Components 106 over unencrypted link TC5, as described below. The transparent interception can be done using standard techniques.

At the other end of the proxy transport 520 there is also an SSL connection TSl between an SSL Client 710 and the Secure Server 90. This is negotiated between the SSL Client 710 and the Secure Server 90 using a method that involves Auxiliary Server Components 706 communicating over unencrypted link TS5, as described below. The SSL negotiation between the SSL Client 710 and Secure Server 90 is initiated after the first transmission in the SSL handshake from the Client Process 12.

After the SSL communications has been set up between the Client Process 12 and the SSL Server 120, and between the Secure Server 90 and the SSL Client 710, data can be securely transferred from the Client Process 12 to the Secure Server 90.

First, the SSL Server 120 decrypts data received from the Client Process 12, sends the decrypted data to a Transformation Module 130 over an unencrypted link TC2. In the Transformation Module 130 the data is transformed and forwarded to a Cryptographic Module 135 over an unencrypted link TC3. The Cryptographic Module 135 encrypts the data and forwards the encrypted data over an encrypted link transport TC4 to a Transport Endpoint 140, which in turn sends the data reliably to the Server Proxy Process 702 over the encrypted Transport Link 520.

On receipt over the Transport Link 520 at a server-side Transport Endpoint 740 in the Server Proxy Process 702, the encrypted data is forwarded over an encrypted link TS4 to a Cryptography Module 735 where the data is decrypted. The decrypted data is forwarded over an unencrypted link TS3, where the data is further transformed. The Transformation Module 730 can then pass the data to the SSL Client 720 over an unencrypted link TS2, where the data is sent over the SSL Connection TSl to the Secure Server 90. Auxiliary Server Components 706 communicates with the SSL Client 710 and the Transformation Module 730 over unencrypted links TS5, TS6, respectively and include data relevant to bypassing the SSL Client 710 using the bypass link TSB.

Likewise, after the SSL communications has been set up between the client process 12 and SSL Server 120, and between the Secure Server 90 and SSL Client 710, data can be securely transferred from the Secure Server 90 to the Client Process 12.

First, the SSL Client 710 decrypts data received from the Secure Server 90, transforms it using the Transformation Module 730, encrypts it using the Cryptography Module 735, and sends it reliably to the Client Proxy Process 102 over the Transport Link 520 using Transport Endpoint 740. On receipt at Transport Endpoint 140 in the Client Proxy Process 102, the data is decrypted in the Cryptography Module 135. The data is further transformed in the Transformation Module 130 and passed to the SSL Server 120, which sends it over the SSL Connection TCl to the Client Process 12.

The Auxiliary Client Components 106 can also communicate with Auxiliary Server Components 706, using the same Transformation Modules 130, 730, Cryptographic Modules 135, 735, and Transport Modules 140, 740 as the SSL communications. Those modules and the ability of the different components of the client proxy and server proxy to communicate using them can be implemented using well-known techniques. When a communication is referred to as being via the proxy tunnel it is to be understood that these components are being used as described above.

In a particular embodiment, the SSL Server 120 and the SSL Client 720 employ Microsoft Windows SChannel implementations. In addition, the Transformation Modules 130, 730 employ format-specific algorithms, including but not limited to those described in U.S. Patent No. 6,253,264, entitled "Coding Network Grouping Data of Same Data Type into Blocks Using File Data Structure and Selecting Compression for Individual Block Base on Block Data Type". The Cryptography Modules 135, 735 employ Microsoft Windows crypto APIs. The Transport Endpoint 140, 740 can employ any suitable transport protocol supported by the proxies, including a persistent transport protocol. However, other implementations can be substituted and therefore such details are omitted from subsequent diagrams.

FIG. 5 is a schematic block diagram of particular client proxy and server proxy components of FIG. 4. In particular, details of the auxiliary components 106, 706 are shown. The auxiliary components communicate through a proxy tunnel 500 using a plurality of link transports 550, 560, 570, 580. For convenience, the client proxy components will be described first, followed by the server proxy components.

Client Proxy Components

As shown in FIG. 5, the Auxiliary Client Components 106 of the Client Proxy Process 102 relate to the Interceptor 110, the SSL Server 120 and the Auxiliary Server Components 706.

The Interceptor 110 participates in the client-side SSL handshake and in subsequent data transfer. It also makes the decision about whether to proxy a particular SSL connection based on the requested network address.

FIG. 6 is a schematic block flow diagram of a particular interceptor module of FIG. 4 participating in a client-side SSL handshake. Activity begins when a message M4 carrying the client SSL HELLO from the Client Process 12 arrives. This message M4 carries the network address of the Secure Server 90. At step 1101, that network address is extracted from the message and retained as a network address datum 1011. At step 1102, the network address 1011 is sent in message M5 to the Client Bypass Checker 170 to determine whether to proxy or bypass the communication. The response from the Client Bypass Checker 170 comes in Message M25 and is processed at step 1103, the result being retained as a proxy result datum 1012.

At step 1104, the proxy result datum 1012 is examined to determine whether to proxy or bypass. If the result is "proxy", the network address 1011 is passed to step 1105; otherwise processing continues to step 1107.

At step 1105, the client HELLO details are passed to the SSL server 120 in Message M26. The handshake is then completed using messages M29a, M29b, M30a, M30b, M31a, M31b, M32a, M32b from the SSL server 120, which are intercepted at step 1106 and then forwarded through the interceptor 110 to the client process 12 to complete the handshake.

If processing is instead directed to step 1107 (i.e. the communication is not to be proxied), the interceptor 110 can, for example, open a network socket to the secure server 90. That open network socket is used at step 1108 to send and receive communications MH with the secure server 90 without encryption or inspection.

Returning to FIG. 5, the SSL Server 120 is responsible for setting up and maintaining an SSL connection with the Client Process 12 so that it can decrypt its data, thereby allowing the unencrypted data to be transformed, perhaps by compressing it. During the SSL handshake, the SSL server 120 supplies an identification certificate chain in response to the client HELLO. This identification certificate chain, which in effect impersonates the Secure Server 90, is obtained dynamically from the Client Bypass Checker 170 and is referred to as an impersonation certificate chain. The end certificate in the chain is referred to as the impersonation certificate.

FIG. 7 is a schematic block flow diagram of a particular SSL Server handshake function. The client HELLO message M26 forwarded by the Interceptor 110 to the SSL server 120 (FIG. 6) is received at step 1201. The data contained in the message is extracted at step 1201 and retained in a Hello message data block 1021.

The first action is to obtain the necessary impersonation certificate chain. This is done, at step 1202, by sending the network address (part of the Hello message data block 1021) to the Client Bypass Checker 170 in a message M27. The impersonation certificate chain is returned in a message M28, extracted in step 1203 and retained in datum 1022. At step 1204, the SSL server 120 chooses its SSL response parameters, retaining them in a data block 1023.

Then, at step 1205, the SSL server 120 sends the SSL response, including the chosen parameters and the impersonation certificate chain back to the Interceptor 110 in Message M29a. This message may in fact include multiple messages (ServerHello, Certificate, and ServerHelloDone) according to the SSL protocol, but this fact is not significant in the context of the system. That message M29a is forwarded to the client process 12, which responds via the interceptor 110 by delivering Message M30b to the SSL Server 120. That message M30b includes the encrypted pre-master secret.

At step 1206, the encrypted pre-master secret is extracted from the message M30b and retained in datum 1024. The pre-master secret was encrypted with the public key contained in the impersonation certificate passed in Message M29a. At step 1207, the pre-master secret is decrypted using the corresponding private key 116-Prv established by the Client Key Manager 160 (see FIG. 10), the result being retained as datum 1025.

The unencrypted pre-master secret 1025 is then used at step 1208 to compute an encryption key (retained as datum 1001), and a MAC key (retained as datum 1002) and handshake MAC over all messages sent to the client (retained as datum 1027). Next the SSL Server 120, at step 1209 receives a further message M31b from the interceptor 110 that includes a MAC computed over the all the original handshake messages sent by the client process 12 up to this point, and retains the value in datum 1028. That message M31b is the SSL Handshake Finished message from the SSL client according to the SSL protocol.

At step 1210, the SSL server 120 uses the MAC key 1002 to compute the MAC of the corresponding messages it has received, retaining it in datum 1029. At step 1211 , the SSL server 120 checks that the handshake MAC of original client messages 1028 against the handshake MAC of received client messages 1029. If the two MACs do not match, then processing continues to step 1212, where the handshake terminates. If the two MACs match, then processing continues to step 1213, where the MAC of the original server messages 1027 is sent to the client process 12 via the interceptor 110 in Message M32. This is the SSL Handshake Finished message from the SSL server, according to the SSL protocol. The handshake is then considered successful at step 1214.

FIG. 8 is a schematic block flow diagram of a particular SSL Server Data Transfer function. Data to be sent to the Secure Server 710 is received in a Message M33b via the interceptor 110. At step 1271, the record is extracted from the message M33b. At step 1272, the record is decrypted using the encryption key 1001 from step 1208 (FIG. 7). Next, at step 1273, the record MAC is computed using the MAC key 1002 from step 1208 (FIG. 7).

At step 1274, the MAC transmitted with the record is compared with the MAC computed for the record. If they are equal, then processing continues to step 1276; otherwise the session is terminated with appropriate error handling at step 1275.

At step 1276, the record payload is passed through the proxy tunnel 500 to the SSL client 710 in Message M34. Subsequently, a response from the secure server 90 via the SSL client 710 may be received through the proxy tunnel in a Message M37. At step 1277, the payload is accepted and stored. For delivery to the client process 12, the payload is processed as follows.

At step 1278, the SSL server 120 computes the MAC for the payload using the MAC key 1270 and appends it to the payload. At step 1279, the appended payload record is encrypted using the encryption key 1260. At step 1280, the record is sent in Message M38a to the interceptor 110 for forwarding to the client process 12.

Returning to FIG. 5 , the Client Certificate Manager 150 may be used to keep the root of the trust chain for the impersonation certificate authority up to date. When the client proxy process 102 starts, the Client Certificate Manager 150 can obtain certificate information from the root certificate (such as issuer name and serial number) and forward that information through the encrypted transport link 550 of the proxy tunnel 500 to the Server Certificate Manager 750. The Server Certificate Manager 750 returns an indication that the certificate is up-to-date, or sends an updated certificate if it is not. If the Client Certificate Manager 150 receives an updated certificate, it deletes the original certificate from the trusted store and then installs the new certificate. This provides support for convenient central administration of the chain of trust.

FIG. 9 is a schematic block flow diagram of a particular Client Certificate Manager (FIG. 5). The operation starts at step 1501. Trusted certificate information is stored in the Trusted Certificate Store 14 (FIG. 5)

At step 1502, the subject name of the root certificate is obtained from configuration data and stored in datum 1051. At step 1503, the root certificate name 1051 is compared to certificate names stored in the Trusted Certificate Store 14. If the name is found, processing continues to step 1504; otherwise processing continues to step 1506.

At step 1504 (certificate exists in the store), the issuer name and the serial number of the certificate is extracted from the Trusted Certificate Store 14 using the root certificate name 1051, and the result is retained in datum 1053. Then, at step 1505, the Client Certificate Manager 150 constructs a record having the issuer name and serial number 1053 and stores that data in a root certificate check request record 1054 to indicate that the certificate status is to be checked. Processing then continues to step 1507.

At step 1506 (certificate does not exist in the store), the Client Certificate Manager 150 constructs a record indicating that a root certificate is needed and stores that data in the root certificate check request record 1054. Processing then continues to step 1507.

At step 1507, the data from the root certificate check request record 1054 (from either step 1505 or step 1506) is placed in a message Ml and sent via the proxy tunnel 500 to the Server Certificate Manager 750.

The Server Certificate Manager 750 returns a message M2 containing a result record. That result data is received at step 1508. At step 1509, the status information is extracted from the record and retained as datum 1055. The status is then checked at step 1510.

If the status indicates that the local certificate has the same information as the one on the server, the process finishes at step 1511. Otherwise, processing flows to step 1513, where the updated certificate is extracted from the record and retained as a new root certificate 1056. At step 1514, the new certificate is then installed or replaced in the Trusted Certificate Store 14. The process then finishes at step 1515.

Returning to FIG. 5, the Client Key Manager 160 ensures that the client proxy 102 has a PKI key pair, and sends the public key information (key, algorithm, parameters) from that key pair over the encrypted transport link 560 of the proxy tunnel 500 to the Server Key Manager 760 where it may be used by the Impersonation Certificate Manager 790 (FIG. 19). This arrangement contributes to the solution of the security issue of having the Certificate Authority located near the client, as described above, by making it possible to locate the impersonation Certificate Authority on the server proxy. The Client Key Manager 160 can create the PKI key pair when the client proxy is first installed or run, and it can check from time to time that it still exists. The public key is included in each impersonation certificate. The SSL Server 120 uses the corresponding private key to decrypt the SSL communication from the Client Process 12. FIG. 10 is a schematic block flow diagram of a particular Client Key Manager (FIG. 5). The operation of the Client Key Manager 160 starts at step 1601. Step 1602 is a check of whether the client proxy key pair exists. If the result of the decision at step 1602 is that the client proxy key pair does not exist, control is transferred to step 1603 , which creates the key pair in the persistent Client Proxy Key Pair store 116, which includes a private key 116-Prv and a public key 116-Pub. Then control is transferred to step 1604.

If client proxy key pair does exist at step 1602 or after the persistent key pair 116 is created at step 1603, control is transferred to step 1604. At this point the public key information 1243 is sent through the proxy tunnel 500 to the Server Key Manager 760 in Message M3.

Returning to FIG. 5, the Client Bypass Checker 170 makes the decision about whether to bypass the communications intercepted by the Interceptor 110. The Interceptor 110 passes the network address of the secure server from the client SSL HELLO to the Client Bypass Checker 170. The Client Bypass Checker 170 can include checks based on local data, such as checking the network address against a list of known network addresses. If such checks indicate the connection should not be proxied, a negative response is sent to the Interceptor 110, which bypasses the connection. If the connection is to be proxied, the Client Bypass Checker 170 gets an impersonation certificate chain from Server Proxy Process 702 over its encrypted transport link 570 and forwards the impersonation certificate chain to the SSL Server 120 (when requested) to assist with completing the client-side SSL handshake. By placing these facilities near the secure server the system can handle the problems identified with having a Certificate Authority too near a client. In addition, the facilities provide a centralized mechanism for restricting the secure servers that can be proxied.

FIG. 11 is a schematic block flow diagram of a particular Client Bypass Checker (FIG. 5). As shown, the Interceptor 110 sends the network address of the Secure Server 90 in a Message M5 that is received by the Client Bypass Checker 170 at step 1701. That network address is retained as datum 1071. Control is transferred to step 1702, which sends the network address 1071 via the proxy tunnel 500 in a message M6 to the Server Bypass Checker 770. The Client Bypass Checker 170 then waits for the response to this request in a return message M24 over the proxy tunnel 500 from the Server Bypass Checker 770.

The response is received at step 1703, which retains the response in datum as a Proxyable Query Result 1072.

Control is transferred to step 1704, which checks the query result 1072. If this check indicates that the connection may be proxied, an impersonation certificate chain is extracted from the response and retained as datum 1073. Then control is transferred to step 1706, which sends the result back to the Interceptor 110 in a message M25. On the other hand, if step 1704 determines that the connection may not be proxied, control is transferred to Block 1706, which uses the message M25 to inform the Interceptor 110 of that fact.

Subsequently, as the SSL Server 120 processes the client SSL handshake, it sends a message M27 having a request for the required impersonation certificate chain to the Client Bypass Checker. That request is received at step 1707, which passes control to step 1708. Step 1708 obtains the impersonation certificate chain from the datum 1073 and returns it to the SSL Server 120 in a message M28.

Returning to FIG. 5, the Client Trust Checker 180 provides a way to determine whether the end certificate of a chain is trusted on the client machine. As input it takes a certificate chain directed to it from the Server Trust Checker 780 over the encrypted transport link 580 of the proxy tunnel 500. It returns a response that indicates whether the end certificate is trusted, and if not, indicates the problem or problems found. In typical implementations, a standard API provided as part of the cryptographic facilities of the operating system (such as the Windows Cryptographic API) is used for checking the trust.

FIG. 12 is a schematic block flow diagram of a particular Client Trust Checker (FIG. 5). As shown at step 1801, the Client Trust Checker 180 receives a Message M 12 (across the proxy tunnel 500) having an identification certificate chain. The aim of the Client Trust Checker 180 is to establish whether or not the end certificate of the chain is trusted. It does this by using the certificate trust-checking and other functions available on the computer. The check is done in at step 1802, which forwards the result (trusted or not, and reason if not trusted) in a Message M13 across the proxy tunnel 500 to the Server Trust Checker 780.

Server Proxy Components

Again, FIG. 5 depicts the content ofthe Auxiliary Server Components 706 of the Server Proxy Process 702, and their relationship to the SSL Client 710 and the Auxiliary Client Components 106.

The SSL Client 710 is responsible for setting up and maintaining an SSL connection to the Secure Server 90. It is responsible for obtaining the identification certificate ofthe Secure Server 90, checking whether it is trusted, and reacting appropriately. In addition to participating in the SSL handshake it forwards and receives data in the data transfer phase ofthe SSL connection.

FIG. 13 is a schematic block flow diagram of a particular SSL Client handshake function. Handshake processing is initiated when a message M8 arrives from the Impersonation Certificate Manager 790 bearing a request for an impersonation certificate and trust status in the form ofthe network address ofthe Secure Server 90. The request message M8 is received at step 7101 and control passes to step 7102, which sends the SSL client HELLO message M9 to the Secure Server 90.

The Secure Server 90 responds with a message MlO, providing SSL cryptography parameters and certificates, which are received at step 7103. The certificate chain provided by the Secure Server 90 is retained in datum 7011. Control is transferred to 7104, which sends the certificate chain data 7011 to the Server Trust Checker 780 in a message Ml 1 to check if the identification certificate is trusted.

The result ofthe trust status assessment is returned by the Server Trust Checker 780 in a message M14, which is received at step 7105, and it is retained as trust status datum 7012. The status includes at least one, and possibly both ofthe results of assessing the trust on the client and server, depending on the configuration ofthe trust checking.

Having received the trust status, step 7106 determines what should be done. This is a matter of configuration. Common practice is to always attempt the connection, and provide the user with an alert that allows the user to make the final decision as to whether to accept the connection or not. Therefore, the flowchart shows that the SSL connection is completed via further messages in every case.

Control is transferred to step 7107, which sends the pre-master secret encrypted with the public key from the identification certificate in the stored certificate chain 7011 to the Secure Server 90 via a message M15. Then step 7108 computes the encryption key (retained as datum 7001), the MAC Key (retained as datum 7002) and the handshake MAC (retained as 7013). Then at step 7109 the handshake MAC 7013 is sent to the Secure Server 90 in a message M16.

The Secure Server 90 responds with a message Ml 7, which contains a handshake MAC computed by the Secure Server 90. The handshake MAC in the message Ml 7 from Secure Server 90 is accepted at step 71 10, which retains it as datum 7014.

At step 7111, that handshake MAC 7014 is compared with the stored handshake MAC 7013 computed at step 7108. If there is a match (the usual case) control is transferred to step 7112, which sends the certificate chain 7011 and trust status 7012 in a message Ml 8 to the Impersonation Certificate Manager 790. Otherwise, the SSL connection attempt is terminated at step 7113.

FIG. 14 is a schematic block flow diagram of a particular SSL Client Data Transfer function. The depicted processing is the usual SSL processing for the data phase of an SSL connection. The top section of the diagram depicts sending data from the client, while the bottom section of the diagram depicts the process by which data is sent from Secure Server 90 to the client.

For sending data from the client, the SSL Server 120 sends a payload across the proxy tunnel 500 in a message M34 to the SSL Client 710, where it is accepted at step 7171. Control is transferred to step 7172, which computes the MAC of the payload and adds it to the payload. The MAC key is stored in datum 7002. Control is then transferred to step 7173, which encrypts the record. The encryption key is stored in datum 7001. Control is transferred to step 7174, where the encrypted record is sent reliably in a message M35 to the Secure Server 90. For processing data sent from the Secure Server 90, an encrypted record is reliably sent by the Secure Server 90 in a message M36, which is accepted at step 7175. Control is passed to step 7176, which decrypts the record using the stored encryption key 7001. Control is then passed to step 7177, which computes the MAC of the payload using the MAC key 7002.

At step 7178, the computed MAC is compared with the MAC contained in the message record (as computed by the sender). If two MACs do not match, which would indicate that the message was altered during transmission, the session is terminated at step 7180. More usually, the MAC comparison is successful, and control is transferred to step 7179, which sends the payload as a message M37 through the proxy tunnel 500 to the SSL Server 120.

Returning to FIG. 5, the Server Certificate Manager 750 participates in keeping the root of the chain of trust up-to-date on the client machine 100. It accepts a message from the Client Certificate Manager 150 via the encrypted transport link 550 of the proxy tunnel 500. The message bears identification that uniquely identifies the certificate that is at the root of the chain of trust for the Certificate Authority certificate of the Impersonation Certificate Authority 792. The Server Certificate Manager 750 compares that information with the current information. If it matches, the Server Certificate Manager 750 sends a message through the proxy tunnel 500 to the Client Certificate Manager 150 indicating that it does not need to update its certificate. Otherwise, the Server Certificate Manager 750 sends the Client Certificate Manager 150 a message that bears the current certificate. This structure can reduce the kind of certificate infrastructure that is maintained.

FIG. 15 is a schematic block flow diagram of a particular Server Certificate Manager (FIG. 5). As describe in FIG. 9, the Client Certificate Manager 150 sends a message Ml having a certificate check request record across the proxy tunnel 50 to the Server Certificate Manager 750.

That certificate check request message Ml is accepted at step 7501. The status information about whether the root certificate is present on the client machine is extracted from the record at step 7502. The certificate status is then stored in datum 7051. Next, at step 7503, a check using the certificate status 7051 determines if the root certificate exists. If the root certificate exists, control passes to step 7504; otherwise control passes to step 7507.

If control passes to step 7504, the record is parsed for the certificate information, which is stored as datum 7053. Control continues to step 7505, which compares the certificate information from the client with equivalent data obtained from the Certificate Store 714. If the two instances of certificate information are equal, control jumps to step 7506, which creates a response data record 7056 that signals that the client copy of the certificate is up-to-date ("OK") and transfers control to step 7508.

On the other hand, if the decision at step 7503 indicates that the root certificate does not exist or if the decision at step 7505 indicates that the certificate information from the two sources are different, control jumps to step 7507. Step 7507 uses data from the Certificate Store 7054 to create a response data record 7056 that includes new certificate information for transmission to the Client Certificate Manager 150. Control then proceeds to step 7508.

At step 7508, the response data record 7056 is sent as the message M2 through the proxy tunnel 500 to the Client Certificate Manager 150.

In the above description of the certificate managers 150, 750 the subject name of the Server Proxy CA certificate was obtained from configuration information associated with the client proxy process 102 and used to populate the Root Certificate Name datum 1051. An alternative embodiment can obtain the subject name for the Server Proxy CA certificate from the Server Certificate Manager 750 using an additional message exchange to populate the Root Certificate Name datum 1051. That message would be accepted at the Server Certificate Manager 750, which would then consult its configuration information to obtain the subject name requested. The Certificate Manager 750 would then forward that data to the client. The Client Certificate Manager 150 would accept this information and store it in datum 1051

Returning to FIG. 5 , the Server Key Manager 760 accepts public key information (key, algorithm, parameters) that has been sent across the encrypted transport link 560 of the proxy tunnel 500 from the Client Key Manager 160. It retains the public key information, and it is used by the Impersonation Certificate Manager 790 in creating impersonation certificates. In typical implementations the public key information is sent by the Client Key Manager 160 the first time the client proxy connects to the server proxy.

FIG. 16 is a schematic block flow diagram of a particular Server Key Manager (FIG. 5). The client proxy public key information 116-Pub is sent by the Client Key Manager 160 in a message M3 across the proxy tunnel 500. That message is received at step 7601. The key information is retained in datum 7006.

Returning again to FIG. 5 , the Server Bypass Checker 770 receives the network address of the Secure Server 90. It uses that network address to determine whether the proxy tunnel 500 should proxy or bypass the communications. To determine the suitability of the network address for proxying, the Server Bypass Checker 770 can use the network address to perform local computations, and it may communicate with other network entities. Such checks can include consulting a local list of allowed addresses; consulting an online registry; contacting the server at the network address supplied, and requesting specific data from it; or comparing with a wildcard domain name with the result of a reverse DNS lookup of the network address. Other available data, such as user credentials, can also be used to determine whether to proxy the connection.

If the client-side SSL connection may be proxied, the Server Bypass Checker 770 obtains an impersonation certificate. It does this by sending the network address to the Impersonation Certificate Manager 790, which returns an impersonation certificate chain to it. the Server Bypass Checker 770 returns an indication of whether the SSL connection may be proxied, and if it can, the impersonation certificate chain is returned as well.

FIG. 17 is a schematic block flow diagram of a particular Server Bypass Checker (FIG. 5). As described in FIG. 11, the Client Bypass Checker 170 sends the network address of the Secure Server 90 across the proxy tunnel 50 in a message M6. That message M6 is accepted by the Server Bypass Checker 770 at step 7701 and retained as datum 7071.

At step 7702, the stored network address 7071 is used to determine if the secure connection is proxyable, as described above. If the connection is proxyable, control jumps to step 7703, and if the connection is not proxyable, control jumps to step 7707. For a proxyable connection, step 7703 forms a request for an impersonation certificate. That request for an impersonation certificate is transmitted to the Impersonation Certificate Manager 790 in a message M7. The Server Bypass Checker 770 then waits for a response.

The Impersonation Certificate Manager 790 responds using a message M23, which is accepted at step 7704. Step 7704 stores the impersonation certificate chain in datum 7073. Control continues to step 7705, which uses the impersonation certificate chain 7073 to create a response record 7072 that indicates the connection is proxyable, and includes the impersonation certificate chain 7073. Control is then transferred to step 7708.

For a not proxyable connection determined at step 7702, step 7707 creates a response record 7072 that indicates "not proxyable" and processing also continues to step 7708.

At step 7708, the response record 7072 as created by either step 7705 or 7707 is transmitted across the proxy tunnel 500 as a message M24 back to the Client Bypass Checker 170.

Returning to FIG. 5 , the Server Trust Checker 780 accepts an identification certificate chain from the SSL Client 710 and checks whether the end certificate in the chain is trusted. It can check the trust in the end certificate on the server proxy, on the client proxy, or on another server. It combines any results of this type and passes the composite result back to the SSL Client 710. This procedure provides one element of the solution of the problem of ensuring that client behavior retains fidelity to its unproxied behavior, because it can use the Client Trusted Certificate Store 14 to determine if the secure server identification certificate is trusted. In addition, the possibility of using trust calculations that are centrally administered (for example, on the server proxy) adds useful administrative power.

FIG. 18 is a schematic block flow diagram of a particular Server Trust Checker (FIG. 5). As described with respect to FIG. 13, the SSL Client 710 sends an identification certificate chain from the Secure Server 90 in a message Ml 1 to the Server Trust Checker 780. That message Ml 1 is accepted at step 7801, which retains the certificate chain data in datum 7081. Control then continues to step 7802, which consults configuration data 7082 to determine whether to assess certificate trust on the client. If certificate trust is to be assessed on the client, control continues to step 7803; otherwise control jumps to step 7805.

At step 7803, the identification certificate chain 7081 is transmitted across the proxy tunnel 500 in a message M12 to the Client Certificate Trust Checker 180. After checking the trust, the Client Certificate Trust Checker 180 transmits the result back across the proxy tunnel 500 to the Server Trust Checker 780 in a message M13, as describe with respect to FIG. 12.

The message M 13 is accepted by step 7804 and the client status information is retained as datum 7083. Processing then continues to step 7805.

Step 7805 determines whether trust should be assessed on the server, based on the configuration data 7082. If yes, control continues to step 7806; otherwise, control jumps to step 7807. Note that at least one of the decisions in steps 7802 or 7805 should have a "yes" outcome.

Step 7806 assesses trust for the end certificate 7081 using local certificate stores (not shown). It retains the result of the trust checking as server status information in datum 7084. Processing then continues to step 7807.

Step 7807 combines the client status information 7083 with the server status information 7084 (or just one of these, if only one of the checks was done) according to an optional algorithm to get a final result. For example the algorithm may require that at least one of the server and client trust the identification certificate. The combined status information is retained as datum 7085. Processing then continues to step 7808.

Step 7808 returns the final combined assessment of trust 70085 to SSL Client 710 in a message M14.

Returning to FIG. 5 , the Impersonation Certificate Manager 790 manages the production of impersonation certificates from identification certificates and sends them across the proxy tunnel 500 to the client proxy. The Impersonation Certificate Manager 790 takes a network address as input. The network address is forwarded to the SSL client 710, where it is used to initiate a connection to Secure Server 90 identified by the network address. The secure server 90 responds with an identification certificate chain that is sent to the SSL Client 710. The SSL Client then passes the identification certificate chain to the Server Trust Checker 780, which checks whether the identification certificate is trusted, and returns the result of that check to the Impersonation Certificate Manager 790. The Impersonation Certificate Manager 790 produces an impersonation certificate chain using the following procedure.

The Impersonation Certificate Manager 790 decodes the identification certificate and creates a certificate request that contains the same version as the identification certificate; a subject name that is the same as in the identification certificate; public key information from the Server Key Manager 760; and all the other attribute information that can be derived from the original certificate. The latter may include certificate extensions such as key and policy information, certification path constraints, and issuer and subject information. If the identification certificate is trusted, the certificate request is passed to the Impersonation Certificate Authority 792, which returns an impersonation certificate chain for which the end certificate will be trusted on the client. If the identification certificate is not trusted, the certificate request is passed to the Error Certificate Authority 796, which returns a single impersonation certificate that is not trusted on the client by signing it with a key for which no chain of trust exists on the client.

The impersonation certificate chain is ultimately returned to the client proxy across the proxy tunnel 500, via Server Bypass Checker 770 and Client Bypass Checker 170. This procedure deals with the problem of having the Certificate Authority too near the client by locating the Certificate Authorities used for impersonation on or near the server proxy. It provides a solution to the problem of reliably providing the domain name by preserving the domain name of the Secure Server 90, wherever it exists in the certificate. It deals with the problem of retaining client behavior because it supplies an untrusted certificate with similar properties to the original when the original certificate is untrusted.

FIG. 19 is a schematic block flow diagram of a particular Impersonation Certificate Manager (FIG. 5). As described above, the Server Bypass Checker 770 sends the network address of the Secure Server 90 to Impersonation Certificate Manager 790 in Message M7. The network address message M7 is accepted at step 7901, which retains the network address as datum 7091. Processing then continues to step 7902.

Step 7902 sends the network address 7091 in a message M8 to the SSL Client 710. The Impersonation Certificate Manager 790 then waits for a response. When the SSL Client 710 responds, processing continues at step 7903.

The response is via a message Ml 8, which includes the identification certificate chain from the Secure Server 90 and the trust status assessment of the identification certificate. At step 7903, the message Ml 8 is accepted and the trust status is retained as datum 7092 and the identification certificate chain is retained as datum 7093. Processing then continues to 7904, which creates a certificate request using data from the identification certificate 7093 and the client proxy public key information 7006 (originally obtained by the Server Key Manager 760 (FIG. 16)). Step 7654 retains the certificate request as datum 7094. Processing then continues to step 7905.

Step 7905 makes a decision based on the trust status information 7092. If the identification certificate was trusted, processing continues to step 7906; otherwise, processing jumps to step 7908.

Step 7906 (trusted certificate) requests a trusted impersonation certificate from the Impersonation Certificate Authority 792, using a message M21. The Impersonation Certificate Authority 792 then responds with the trusted impersonation certificate chain in a message M22. That message M22 is accepted at step 7907, which retains the trusted impersonation certificate chain in datum 7095. Processing then continues to step 7910.

Step 7908 (untrusted certificate) sends the certificate request 7094 in a message M21e to Error Certificate Authority 796. The Error Certificate Authority 796 responds with an untrusted impersonation certificate chain in a message M22e. That message M22e is accepted at step 7909 and the untrusted impersonation certificate chain is retained as the impersonation certificate chain 7095. Processing then continues to step 7910.

At step 7910 the impersonation certificate chain 7095 (either trusted from step 7907 or untrusted from step 7909) is transmitted to the Server Bypass Checker 770 in a message M23. FIG. 20 is a schematic block flow diagram of a particular Impersonation Certificate Authority (FIG. 5). As described, the Impersonation Certificate Manager 790 sends the Impersonation Certificate Authority 792 a certificate request in a message M21. The Impersonation Certificate Authority 792 accepts the request at step 7921. Processing continues to step 7922, which creates an impersonation certificate chain. Processing continues to step 7923, which sends the impersonation certificate chain back to Impersonation Certificate Manager 790 in a message M22.

FIG. 21 is a schematic block flow diagram of a particular Error Certificate Authority (FIG. 5). As described, the Impersonation Certificate Manager 790 sends the Error Certificate Authority 796 a certificate request in a message M21e. The Error Certificate Authority 796 accepts the request at step 7961. Processing continues to step 7962, which creates a certificate. Processing continues to step 7963, which sends the certificate back to the Impersonation Certificate Manager 790 in a message M22e.

Message Flow and Sequence of Events

From the above drawings and description, one can follow the message flows between the client process and the secure server. For convenience, those flows are graphically depicted in FIGs. 22A, 22B, and 23.

FIG. 22A is a message flow diagram for messages on the client side of the system of FIG. 4, and FIG. 22B is a message flow diagram for messages on the server side of the system of FIG. 4. As shown, the communication to the Secure Server 90 can be proxied and the identification certificate of the Secure Server 90 is trusted on the client.

FIG. 23 is a message flow diagram for messages client proxy and server proxy of FIG. 4. FIG. 23 does not show the detail of all messages to and from the Transformation Modules 130, 730, Cryptography Modules 135, 735, and Transport Modulesl40, 740. Messages that traverse those modules of the proxy tunnel are combined into a single message.

In a particular implementation, some messages may be combined. For example, more than one message carries the network address across the proxy tunnel. As well, there is some flexibility in the choice of which aspects of the invention to implement. For example, it is possible to check the trust in the secure server identification only on the server, saving a round trip across the client-proxy link, and so increasing the transport efficiency. The diagrams keep the messages separate to more clearly illustrate the interaction of the components of the system. As a general principle, round trips across the proxy tunnel should be reduced as much as possible.

As shown, when the client proxy process connects to the server proxy it begins by sending the message containing its trust root certificate information Ml from the Client Certificate Manager 150 to the server. That message Ml is sent across the proxy tunnel 500 to the Server Certificate Manager 750, which compares the information with the current data of the trust root. Based on the result it sends a message M2 back to the Client Certificate Manager 150. If the certificate information matches, an "OK" indication is returned in that message M2. Otherwise, an updated certificate is returned. In that case the updated certificate is used to replace the original in the trusted store. This may require explicit permission from the end- user.

Before proxying an SSL connection, client proxy public key information is sent to the server proxy. This is done in a message M3 from the Client Key Manager 160 to the Server Key Manager 760. The Server Key Manager 760 retains the key information for later use.

When the Client Process 12 sends an SSL Client HELLO message M4, that message is intercepted by the Interceptor 110. The Interceptor 110 determines whether or not to proxy this SSL communication. The Interceptor 110 extracts the network address from the intercepted message and passes it in Message M5 to the Client Bypass Checker 170.

The Client Bypass Checker 170 makes any local checks that are required, and then sends Message M6 through the proxy tunnel to the Server Bypass Checker 770. The Server Bypass Checker 770 uses the network address in the message, and possibly other information available to it to determine whether to proxy the SSL session.

If the SSL communication is to be proxied, the Server Bypass Checker 770 forwards the network address to the Impersonation Certificate Manager 790 in Message M7, in effect requesting an impersonation certificate. The Impersonation Certificate Manager 790 passes the network address to the SSL Client 720 in Message M8. The SSL Client 720 sends the SSL client HELLO message M9 to the Secure Server 90. The Secure Server 90 responds to the SSL Client 720 with its identification certificate chain (and other data) in Message MlO.

The SSL Client 720 forwards the certificate chain to the Server Trust Checker 780. The Server Trust Checker 780 can simply check the trustworthiness of the identification certificate using the trusted store on the server proxy machine, or it can forward the identification certificate chain across the proxy tunnel 500 to the Client Trust Checker 180 in Message M12. In that case the response is communicated to the Client Trust Checker 180 in Message M13, and this is forwarded to the SSL Client 720 in Message M14. In this way, the SSL Client 720 can delegate its trust checking function to the Client Trust Checker 180.

Once trust has been established, the SSL Client 720 completes the SSL handshake using messages M15, M16, M17. When the SSL handshake has been completed successfully, the SSL Client 720 forwards the identification certificate chain to the Impersonation Certificate Manager 790 in Message Ml 8. This message is the response to Message M8. As a side-effect of completing the response, there is a completed SSL connection on the server side.

The Impersonation Certificate Manager 790 now creates the impersonation certificate. The Impersonation Certificate Manager 790 first obtains the client proxy public key information that the Server Key Manager 760 originally obtained. It then creates a certificate request, using the information in the identification certificate but replacing the public key information with the client proxy public key information. It then forwards this information as a certificate request in Message M21 to the Impersonation Certificate Authority 792 (if the identification certificate is trusted) or as certificate request Message M21e to the Error Certificate Authority 796 (if the identification certificate is not trusted). The certificate chain having the requested impersonation certificate is sent back in Message M22 (from the Impersonation Certificate Authority 792) or Message M22e (from the Error Certificate Authority 796). This is passed back to the Server Bypass Checker 770 in Message M23, in effect completing the request for an impersonation certificate implied in Message M7. The Server Bypass Checker 770 returns the impersonation certificate chain across the proxy tunnel in Message M24 to the Client Bypass Checker 170, implying that the connection is to be proxied. The impersonation certificate chain is retained for use in setting up the client-side SSL connection.

The Client Bypass Checker 170 sends Message M25 to the Interceptor 110, allowing it to proxy the SSL connection. The Interceptor 110 forwards the SSL client HELLO message that was originally delivered in M4 to the SSL Server 120 in Message M26. The SSL Server 120 uses Message M27 to request an impersonation certificate from the Client Bypass Checker 170, and the Client Bypass Checker 170 responds with Message M28 having the impersonation certificate chain that was obtained earlier.

The SSL Server 120 then passes the impersonation certificate to the Client Process 12 as part of its response to the SSL client HELLO, using Message M29a to the Interceptor 110, which is forwarded as M29b to the Client Process 12. The client-side handshake is completed via messages M30a, M30b, M31a, M31b, M32a, and M32b.

Requests can now be sent across the proxy tunnel 500. To send a request, the Client Process 12 sends an encrypted request Message M33a and it is intercepted by the Interceptor 110. The Interceptor 110 forwards the Message M33b to SSL Server 120, which decrypts it using the shared cryptographic material it has negotiated with the Client Process 12. The decrypted request is transformed, encrypted and sent reliably across the proxy tunnel 500 to the SSL Client 720 in Message M34.

On the server side the message is decrypted, transformed again and sent to the Secure Server 90 in the encrypted Message M35. The Secure Server 90 responds to the SSL Client 720 in encrypted Message M36. The SSL Client 720 decrypts the response using the cryptographic material it has negotiated with the Secure Server 90. The SSL Client 720 transforms the response, encrypts it and sends it reliably across the proxy tunnel in Message M37.

The response is decrypted inside the client proxy, transformed again and passed to the SSL Server 120. The SSL Server 120 encrypts the response using the shared cryptographic material it has negotiated with the Client Process 12, and forwards it via the Interceptor 110 using message M38a. The Interceptor 110 forwards it to the Client Process 12 in Message M38b. Context of the System in the Internet

FIG. 24 is a schematic block diagram showing an application of the present system in the Internet context. As shown a first Client Machine 100-1 includes a first Client Proxy Process 102-1, which intercepts communications from multiple Client Processes 12-1, 12-2, 12-3. A second Client Machine 100-2 includes a second Client Proxy Process 102-2. The second Client Proxy Process 102-2 intercepts communications from multiple Client Processes 12-4, 12-5, 12-6.

An Enterprise network 800-1 includes a Server Proxy Machine 702-1. The communication stream between a Client Process 12-1 and a Secure Server 90- 1 is conducted through stream slO (intercepted), stream si 1 (inside the proxy tunnel between the Client Proxy Process 102-1 and the Server Proxy Machine 702-1), and stream sl2 (between the Server Proxy Machine 702-1 and the Secure Server 90-1). Other similarly proxied communication streams are depicted as further examples.

FIG. 24 also illustrates bypassed secure communication streams. The communication between Client Process 12-6 and Secure Server 90-4, which is outside the Enterprise 800-1 is transmitted by means of communication streams si 6 between the Client Process 12-6 and its Client Process Proxy 102-2, and stream si 7 outside the proxy tunnel from the Client Process Proxy 102-2 to the Secure Server 90-4, the communications being passed on without inspection or modification.

It should be understood that embodiments of the invention can be used in non- Internet applications. Furthermore, even in Internet applications it is not necessary for the end user to physically enter the domain name of the secure server into a web browser.

It is understood that although only two client machines are shown, there may be any number of client machines. Similarly, although only three client processes are shown on each client machine, there may be any number of client processes on each client machine. Furthermore, although two communication streams are shown for some of the client processes, there may be any number of communication streams from each client process. In addition, although the client processes that are shown communicate individually with either enterprise servers or non-enterprise servers, each process may communicate with any number of enterprise or non-enterprise servers, and may have any number of connections to any one enterprise server independent of its connections to any other.

It is also understood that although only one server proxy is shown, each client proxy may communicate with any number of server proxies. Also, although the server proxy is depicted within an enterprise, a server proxy may be shared by multiple enterprises or for similar or different purposes by multiple interested parties. Furthermore, although the server proxy is shown connecting directly to a secure server, it may use the HTTP CONNECT method to connect via a proxy.

In addition, although a client proxy is shown as operating on each client machine, a single client proxy, possibly on a separate machine from any of the client machines, may intercept and process communications from any number of client machines.

Although interception of communication streams is shown as a function of the client proxy or proxies, additional software or hardware, or both, may be used to perform the interception function. Network entities for such interception are situated logically between the client process and the client proxy and transparently forward packets between these two entities.

Wherever SSL communication is referred to, it is understood that TLS communication, or more generally, any secure communications protocol based on similar shared key principles of PKI or other suitable infrastructures can be used.

Those of ordinary skill in the art should recognize that methods for the disclosed proxies may be embodied in a computer program product that includes a computer usable medium. For example, such a computer usable medium can include a readable memory device, such as a solid state memory device, a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having stored computer readable program code segments. The computer readable medium can also include a communications or transmission medium, such as a bus or a communications link, either optical, wired, or wireless, carrying program code segments as digital or analog data signals. While the system has been particularly shown and described with references to particular embodiments, it will be understood by those of ordinary skill in the art that various changes in form and details may be made without departing from the scope of the invention encompassed by the issued claims. For example, the methods of the invention can be applied to various environments, and are not limited to the described environment.

Claims

CLAIMSWhat is claimed is:

1. A secure communications system between two remote processes running on respective computers, comprising: a proxy tunnel for exchanging secure data over an unsecure medium; and a first proxy component of a distributed man-in-the-middle proxy, the first proxy component disposed between and in communication with the proxy tunnel and a first process.

2. The system of Claim 1 wherein the unsecure medium is a public network.

3. The system of Claim 2 wherein the public network is the Internet.

4. The system of Claim 1 wherein the first process is a secure server process

5. The system of Claim 1 wherein the first process is a client process in a client-server system.

6. A secure communications system between two remote processes running on respective computers, comprising: a proxy system formed between a first process and a second processes, the proxy system comprising: a first proxy process in communication with the first process to proxy the second process, the first proxy process having a first proxy cryptography key; a second proxy process in communication with the second process to proxy the first process, where the second proxy process includes a security certificate using at least a portion of the first proxy cryptography key; a proxy tunnel to exchange data between the first proxy process and the second proxy process; and a Communications link for exchanging encrypted data between the first process and the second process, the communication link including the proxy tunnel and a secure link established between the first process and the first proxy process using the security certificate.

7. The system of Claim 6 wherein the first process is a security-enabled client process and the second process is a secure server process.

8. The system of Claim 6 wherein the secure link employs a shared cryptography key protocol.

9. The system of Claim 8 wherein the cryptography key includes a private key and a public key and the security certificate uses the public key.

10. The system of Claim 6 wherein the first proxy process detects whether the second process can be securely proxied.

11. The system of Claim 10 wherein the first proxy process bypasses the proxy tunnel when a second process cannot be proxied.

12. The system of Claim 6 wherein the proxy system includes a compression module for compressing data to be transmitted through the proxy tunnel.

13. The system of Claim 6 wherein the proxy system is transparent to at least one of the first process or the second process.

14. A secure communications system between two remote processes running on respective computers, comprising: a first proxy process having a first proxy cryptography key, the first proxy process in communication with a first process and disposed between the first process and a proxy tunnel, the first proxy process proxying a second process located across the proxy tunnel; and a communications link for exchanging encrypted data between the first process and the second process, the communication link including the proxy tunnel and a secure link between the first process and the first proxy process using a security certificate received from the proxy tunnel, wherein the security certificate includes at least a portion of the first proxy cryptography key.

15. The system of Claim 14 wherein the first process is a security-enabled client process and the second process is a secure server process.

16. The system of Claim 14 wherein the secure link employs a shared cryptography key protocol.

17. The system of Claim 16 wherein the first proxy cryptography key includes a private key and a public key, and wherein the security certificate uses the public key.

18. The system of Claim 14 wherein the first proxy process detects whether the second process can be securely proxied.

19. The system of Claim 18 wherein the first proxy process bypasses the proxy tunnel when a second process cannot be proxied.

20. The system of Claim 14 wherein the first proxy process includes a compression module for compressing data to be transmitted to the second process.

21. A secure communications system between two remote processes running on respective computers, comprising: a first proxy process, the first proxy process in communication with a first process over a secure link and disposed between the first process and a proxy tunnel, the first proxy process proxying a second process located across the proxy tunnel; a communications link for exchanging encrypted data between the first process and the second process, the communication link including the proxy tunnel; and an impersonation security certificate that includes at least a portion of a cryptography key received from the proxy tunnel.

22. The system of Claim 21 wherein the first process is a secure server process and the second process is a security-enabled client process.

23. The system of Claim 21 wherein the secure link employs a shared cryptography key protocol.

24. The system of Claim 23 wherein the security certificate uses a public key.

25. The system of Claim 21 wherein the first proxy process includes a compression module for compressing data to be transmitted over the proxy tunnel.

26. A proxy tunnel communication system between a client process running on a client computer and a secure server process running on a secure server computer, comprising: a client proxy process for intercepting a communication stream directed to a secure server process from a client process and associating the communication stream with a client proxy cryptography key pair, including a client proxy private key and a client proxy public key; a proxy tunnel between the client proxy process and a server proxy process associated with the secure server process, the server proxy process including a copy of the client proxy public key for the communication stream and a security certificate generated from the client proxy public key; and a proxy between the client process and the secure server process, in which the security certificate is used to establish a secure communication link between the client process and the client proxy.

27. The system of Claim 26 wherein the security certificate further includes domain name information for the secure server process.

28. A method for providing secure communications between two remote processes running on respective computers, comprising: exchanging secure data over an unsecure medium through a proxy tunnel; and disposing a first proxy component of a distributed man-in-the -middle proxy between and in communication with the proxy tunnel and a first process.

29. The method of Claim 28 wherein the unsecure medium is a public network.

30. The method of Claim 29 wherein the public network is the Internet.

31. The method of Claim 28 wherein the first process is a secure server process

32. The method of Claim 28 wherein the first process is a client process in a client- server system.

33. A method for providing secure communications between two remote processes running on respective computers, comprising: forming a proxy system formed between a first process and a second process, comprising: in a first proxy process in communication with the first process, proxying the second process such that the first process communicates with the second process through the first proxy process, the first proxy process having a first proxy cryptography key; in a second proxy process in communication with the second process, generating a security certificate using at least a portion of the first proxy cryptography key and proxying the first process such that the second process communicates with the first process through the second proxy process; in the second proxy process, proxying the first process such that the second process communicates with the first process through the second proxy process; exchanging data between the first proxy process and the second proxy process through a proxy tunnel; and exchanging encrypted data between the first process and the second process through a communications link, the communication link including the proxy tunnel and a secure link established between the first process and the first proxy process using the security certificate generated by the second proxy process.

34. The method of Claim 33 wherein the first process is a security-enabled client process and the second process is a secure server process.

35. The method of Claim 33 wherein the secure link employs a shared cryptography key protocol.

36. The method of Claim 35 wherein the cryptography key includes a private key and a public key, and the security certificate uses the public key.

37. The method of Claim 33 wherein the first proxy process detects whether the second process can be securely proxied.

38. The method of Claim 37 wherein the first proxy process bypasses the proxy tunnel when a second process cannot be proxied.

39. The method of Claim 33 wherein the proxy system includes a compression module for compressing data to be transmitted through the proxy tunnel.

40. The method of Claim 33 wherein the proxy system is transparent to at least one of the first process or the second process.

41. A method of providing secure communications between two remote processes running on respective computers, comprising: disposing a first proxy process between a first process and a proxy tunnel, the first proxy process proxying a second process located across the proxy tunnel, the first proxy process in communication with the first process and having a first proxy cryptography key, and exchanging encrypted data between the first process and the second process through a communication link, the communication link including the proxy tunnel and a secure link between the first process and the first proxy process using a security certificate received from the proxy tunnel, wherein the security certificate includes at least a portion of the first proxy cryptography key.

42. The method of Claim 41 wherein the first process is a security-enabled client process and the second process is a secure server process.

43. The method of Claim 41 wherein the secure link employs a shared cryptography key protocol.

44. The method of Claim 43 wherein the first proxy cryptography key includes a private key and a public key, and wherein the security certificate uses the public key.

45. The method of Claim 41 wherein the first proxy process detects whether the second process can be securely proxied.

46. The method of Claim 45 wherein the first proxy process bypasses the proxy tunnel when a second process cannot be proxied.

47. The method of Claim 41 wherein the first proxy process includes a compression module for compressing data to be transmitted to the second process.

48. A method of providing secure communication between two remote processes running on respective computers, comprising: operating a first proxy process between the first process and a proxy tunnel, the first proxy process in communication with a first process over a secure link and the first proxy process proxying a second process located across the proxy tunnel; exchanging encrypted data between the first process and the second process over a communications link, the communication link including the proxy tunnel; and computing an impersonation security certificate that includes at least a portion of a cryptography key received from the proxy tunnel.

49. The method of Claim 48 wherein the first process is a secure server process and the second process is a security-enabled client process.

50. The method of Claim 48 wherein the secure link employs a shared cryptography key protocol.

51. The method of Claim 50 wherein the security certificate uses a public key.

52. The method of Claim 48 wherein the first proxy process includes a compression module for compressing data to be transmitted over the proxy tunnel.

53. A method of operating a proxy tunnel between a client process running on a client computer and a server process running on a secure server computer, comprising: in a client proxy process, intercepting a communication stream directed to a secure server process from a client process and associating the communication stream with a client proxy cryptography key pair, including a client proxy private key and a client proxy public key; forming a proxy tunnel between the client proxy process and a server proxy process associated with the secure server process; in the server proxy process: storing a copy of the client proxy public key for the communication stream; generating a security certificate using the client proxy public key; and forming a proxy between the client process and the secure server process, in which the security certificate is used to establish a secure communication link between the client process and the client proxy.

54. The method of Claim 53 wherein the security certificate further includes domain name information for the secure server process.

55. An article of manufacture, comprising: a machine- readable medium; a set of machine-readable instructions on the medium, the instructions providing a method for providing secure communications between two remote processes running on respective computers, comprising instructions for: exchanging secure data over an unsecure medium through a proxy tunnel; and disposing a first proxy component of a distributed man-in-the -middle proxy between and in communication with the proxy tunnel and a first process.

56. An article of manufacture, comprising: a machine- readable medium; a set of machine-readable instructions on the medium, the instructions providing a method for providing secure communications between two remote processes running on respective computers, comprising instructions for: forming a proxy system formed between a first process and a second process, comprising: in a first proxy process in communication with the first process, proxying the second process such that the first process communicates with the second process through the first proxy process, the first proxy process having a first proxy cryptography key; in a second proxy process in communication with the second process, generating a security certificate using at least a portion of the first proxy cryptography key and proxying the first process such that the second process communicates with the first process through the second proxy process; in the second proxy process, proxying the first process such that the second process communicates with the first process through the second proxy process; exchanging data between the first proxy process and the second proxy process through a proxy tunnel; and exchanging encrypted data between the first process and the second process through a communications link, the communication link including the proxy tunnel and a secure link established between the first process and the first proxy process using the security certificate generated by the second proxy process.

57. An article of manufacture, comprising: a machine- readable medium; a set of machine-readable instructions on the medium, the instructions providing a method for providing secure communications between two remote processes running on respective computers, comprising instructions for: disposing a first proxy process between a first process and a proxy tunnel, the first proxy process proxying a second process located across the proxy tunnel, the first proxy process in communication with the first process and having a first proxy cryptography key, and exchanging encrypted data between the first process and the second process through a communication link, the communication link including the proxy tunnel and a secure link between the first process and the first proxy process using a security certificate received from the proxy tunnel, wherein the security certificate includes at least a portion of the first proxy cryptography key.

58. An article of manufacture, comprising: a machine- readable medium; a set of machine-readable instructions on the medium, the instructions providing a method for providing secure communications between two remote processes running on respective computers, comprising instructions for: operating a first proxy process between the first process and a proxy tunnel, the first proxy process in communication with a first process over a secure link and the first proxy process proxying a second process located across the proxy tunnel; exchanging encrypted data between the first process and the second process over a communications link, the communication link including the proxy tunnel; and computing an impersonation security certificate that includes at least a portion of a cryptography key received from the proxy tunnel.

59. An article of manufacture, comprising: a machine- readable medium; a set of machine-readable instructions on the medium, the instructions providing a method for providing secure communications between two remote processes running on respective computers, comprising instructions for: in a client proxy process, intercepting a communication stream directed to a secure server process from a client process and associating the communication stream with a client proxy cryptography key pair, including a client proxy private key and a client proxy public key; forming a proxy tunnel between the client proxy process and a server proxy process associated with the secure server process; in the server proxy process: storing a copy of the client proxy public key for the communication stream; generating a security certificate using the client proxy public key; and forming a proxy between the client process and the secure server process, in which the security certificate is used to establish a secure communication link between the client process and the client proxy.