Method for authenticated communications incorporating intermediary appliances

Method for managing appliance authentication. In one embodiment, the method comprises generating, by a server, a first secret and a second secret from a certificate; transmitting from the server to a client computer, via a first channel secured and trusted based on a trusted computer, the first secret and the second secret; presenting the certificate to an appliance in response to a secure channel request from the appliance, wherein the appliance is holding the first secret; receiving, from the appliance, a description of a second channel, via the appliance, between the client computer and the server; establishing a trust in the second channel based on the description; and transmitting, in response to the trust in the second channel, via the second channel, channel information that comprises a portion of the description signed by the second secret.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention relate generally to techniques for managing authentication of intermediary apparatus located in the network path between a client device and a server.

2. Description of the Related Art

It is relatively common for a network to comprise one or more intermediary appliances, such as Wide Area Network (WAN) accelerators or virus detection devices, inserted in the path between a client device (e.g., a personal computer) and a server (e.g., an application server or server enabled to provide remote desktop services). To maintain secure coupling between the client and the server, the intermediary appliance is generally pre-configured to be included in the trust domain of the server or has the certificate authority to establish trust with a client such that it may intercept and modify secure communications between the client and the server. In such topologies, clients are generally also burdened with maintaining signed certificates and related certificate management infrastructure in order for them to connect to intermediary appliances and initiate a secure session.

However, selective insertion of authorized intermediary appliances in a secure manner remains challenging and therefore there is a need in the art for a method of authenticating such authorized intermediary appliances while also rejecting authentication of, or participation by, unauthorized appliances capable of orchestrating man-in-the-middle (MITM) attacks or other malicious behavior.

SUMMARY OF THE INVENTION

Embodiments of the present invention generally relate to a method for managing appliance authentication. In one embodiment, the method comprises generating, by a server, a first secret and a second secret from a certificate; transmitting from the server to a client computer, via a first channel secured and trusted based on a trusted computer, the first secret and the second secret; presenting the certificate to an appliance in response to a secure channel request from the appliance, wherein the appliance is holding the first secret; receiving, from the appliance, a description of a second channel, via the appliance, between the client computer and the server; establishing a trust in the second channel based on the description; and transmitting, in response to the trust in the second channel, via the second channel, channel information that comprises a portion of the description signed by the second secret.

DETAILED DESCRIPTION

The invention may be implemented in numerous ways, including as a process, an article of manufacture, an apparatus, a system, and as a set of computer-readable descriptions and/or instructions embedded on and/or in a non-transitory computer-readable medium such as a computer-readable storage medium. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. The Detailed Description provides an exposition of one or more embodiments of the invention that enable improvements in features such as performance, power utilization, cost, scalability, efficiency, and utility of use in the field identified above. The Detailed Description includes an Introduction (“Overview”) to facilitate the more rapid understanding of the remainder of the Detailed Description. Additionally, the invention encompasses all possible modifications and variations within the scope of the issued claims.

The term processor as used herein refers to any type of processor, CPU, microprocessor, microcontroller, embedded processor, media processor, graphics processor, or any other programmable device capable of executing and/or interpreting instructions in a form of software (such as microcode, firmware and/or programs).

The term software as used herein refers to any type of computer-executable instructions for any type of processor, such as programs, applications, scripts, drivers, operating systems, firmware, and microcode. Computer-executable instructions include any types of instructions performed by a processor, such as binary instructions that are directly performed, instructions that are translated and/or decoded prior to being performed, and instructions that are interpreted.

An authorized appliance or computer, as described herein, comprises an appliance or computer in possession of a self-signed certificate traceable to a trusted computer (in which the self-signed certificate may not be traceable to a Certificate Authority (CA)) or a verifiable certificate such as a secure socket layer (SSL) certificate signed by a Certificate Authority (CA).

The term “secure” as used herein generally refers to a channel created between two devices that utilize a common secret to ensure the channel cannot be understood or modified by a third party. However, the presence of a secure channel does not pre-suppose that a trust relationship exists between the two devices. For example, one device may establish a secure channel with a misrepresented second device in which case the secure channel is not trusted.

The term “trust” as used herein generally refers to communications between two devices in which the second device has presented a certificate by the first device that is traceable to a certificate authority (CA) recognized by the second device. Since certificates are verified using a secure channel, trusted communications are generally also secure.

An ‘application session’ as defined herein comprises trusted exchange of data (e.g., media data such as compressed display information associated with a hosted application or hosted desktop, file data or other multimedia exchanges such as video) between a client endpoint (comprising a client device or client application software) and server application software, optionally including manipulation of the data (e.g., data compression) by one or more authorized intermediary appliances.

OVERVIEW

A client initiates an authentication process that enables the client to selectively allow one or more authorized intermediary appliances located in a network path between the client and an application server to participate in a subsequent secure application session established between the client and the application server while ensuring that non-authorized appliances or other devices are barred from compromising the security of the application session. In an exemplary embodiment, a Virtualized Desktop Infrastructure (VDI) client establishes a secure remote computing session (i.e., ‘application session’ or ‘application protocol’ session) with a virtualized desktop (i.e., the application server hosts a set of virtualized desktop computers, each enabled to establish an application session with a VDI client using a suitable remote desktop protocol) and the authorized intermediary appliances comprise paired WAN acceleration devices enabled to compress network data associated with the application session.

DETAILED DESCRIPTION

FIG. 1illustrates selected details of an embodiment of a networked client-server system100(“system100”) comprising a client160communicatively coupled to an application server (AS)102via a network180and intermediary appliances, including a security gateway (SG)120, datacenter appliance (DA)130and a branch appliance (BA)140. For clarity, AS102is termed an ‘application’ server to distinguish its role from other server roles defined by the present specification. In practice, AS102may operate as a server, a peer or a client outside of its endpoint role in the authentication method described herein.

The AS102generally comprises a server hardware platform known to the art, such as a server blade from a manufacturer such as HP, Cisco or IBM, or a workstation computer and peripheral equipment, enabled to execute well known operating system software (e.g., one or more instances of Microsoft Windows operating system software), optionally in conjunction with hypervisor software known to the art (e.g., ESX, XenServer or VERDE Hypervisor products from VMware, Citrix and Virtual Bridges Corporations respectively), typically located in memory106. The AS102may also comprise application software services (such as Microsoft Terminal Services (TS)) or software (such as “View Agent” from VMware) enabled to provide remote access to individual desktops and/or applications, such as word processing software, spreadsheets, financial data presentation, video or photo display or editing software, graphics software such as Computer Aided Design (CAD) software, Desktop Publishing (DTP) software, digital signage software, or the like, via TS or Virtualized Desktop Infrastructure (VDI).

The AS102comprises application server connection service (ASCS)112for facilitating the secure connection of one or more client computers160(shown as a client160-1and a client160-2) to AS102. In an exemplary VDI embodiment in which system100provides remote desktop services, a plurality of virtual machine are configured in memory106, each virtual machine comprising an operating system and applications enabled to render display images into virtualized frame buffers, an ASCS112and a set of encoding services for enabling remote access to graphics (e.g., desktop images) by encoding the virtualized frame buffers, peripheral device functions (e.g., Universal Serial Bus (USB)) and audio functions that support the coupling of peripheral device data between applications in ASCS112and devices located at a remote client. As such, memory106may comprise a plurality of unique independently addressable instances of ASCS112, each associated with a separate operating system and domain name (i.e., in an embodiment, different instances of ASCS112may be contacted using different Fully Qualified Domain Names (FQDN)).

The processor system104typically comprises one or more central processing units (CPUs), optionally one or more graphical processing units (GPUs) or a combination of CPU and GPU processing elements. Examples of a well-known suitable CPU include workstation or server class processors such as 32-bit, 64-bit, or other CPUs including XEON or OPTERON class microprocessors manufactured by INTEL and AMD Corporations respectively. However, any other microprocessor platform designed to perform the data processing methods described herein may be utilized. In an embodiment, the processor system104and network interface108are coupled to memory106by one or more bus structures, such as memory and/or Input/Output (I/O) busses known to the art with the aid of support circuits, including at least one of north bridge, south bridge, chipset, power supplies, clock circuits, data registers and I/O interfaces. The support circuits include at least one of address, control, interrupt and/or data connections, controllers, data buffers, drivers, repeaters, and receivers to enable appropriate communications between the processor system104, memory106, and network interface108. In some embodiments, the support circuits further incorporate hardware-based virtualization management features, such as emulated register sets, address translation tables, interrupt tables, Peripheral Component Interconnect (PCI) I/O virtualization (10V) features, and/or I/O memory management unit (IOMMU).

The memory106comprises any one or combination of volatile computer readable media (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), extreme data rate (XDR) RAM, Double Data Rate (DDR) RAM and the like) and nonvolatile computer readable media (e.g., read only memory (ROM), hard drive, tape, CDROM, DVDROM, magneto-optical disks, Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash EPROM and the like). Moreover, memory106may incorporate electronic, magnetic, optical, and/or other types of storage media. Network interface108generally provides compatibility with the network180and delivers services including Internet Protocol (IP) and Transmission Control Protocol (TCP) and/or unreliable datagram services such as User Datagram Protocol (UDP) services.

Client160is generally any form of computing device enabled by a processor and support circuitry to execute the functions of client connection service (CCS)162and connect to network180. For example, in an embodiment, client160is a remote terminal in a networked computer system. Such remote terminals include zero- or thin-clients, personal or tablet computers, workstations, personal digital assistants (PDAs), wireless devices, and the like. In some embodiments, client160incorporates an image decoder that decodes image information for presentation on one or more local display devices, in the form of a remote Graphical User Interface (GUI). In other embodiments, client160also comprises one or more peripheral devices such as mouse, keyboard, and/or other well-known peripherals. CCS162generally comprises a set of machine executable software or firmware instructions (stored in memory of client160) and software data structures enabled to facilitate a secure connection between client160and AS102, including authorized intermediary appliances such as datacenter appliance (DA)130and branch appliance (BA)140.

The connection manager (CM)150is a trusted computer with a certificate store comprising a verifiable certificate such as a self-signed certificate or a certificate traceable to a CA. CM150provides well-known connection management services for authenticating identified users of client160in advance of allowing connections between client160and AS102, generally facilitated by directory resources such as Microsoft Active Directory, RSA Authentication Manager or the like. CM150generally comprises server hardware resources (e.g., part of a blade server), operating system and connection management software such as ‘View Connection Server’, ‘Desktop Studio’ or ‘RD Connection Broker’ software from VMware, Citrix and Microsoft or similar products from companies such as Leostream Corporation. In an embodiment, CM150is coupled to a trusted sub-net of network180(i.e., to network180-1) and a security gateway (SG)120provides a proxy service that enforces restricted secure access to CM150(e.g., via Secure Socket Layer (SSL) or Hypertext Transfer Protocol Secure (HTTPS) protocols).

The network180comprises a communication system (e.g., the Internet, LAN, Wide Area Network (WAN), and the like) that utilizes common 4-tuple network addressing (i.e., combination of IP addresses and port numbers) that connects computer systems completely by wire, cable, fiber optic, and/or wireless links facilitated by various types of well-known network elements, such as Domain Name System (DNS) servers, Certificate Authorities (CA), CM150, Network Address Translation (NAT) gateways, hubs, switches, routers, firewalls, and the like. The network180may employ various well-known protocols, such as security protocols, to communicate information amongst the network resources. In an embodiment, the network180comprises a first trusted datacenter portion (shown as network180-1coupled to AS102and SG120) which is typically a private network isolated by a firewall, a second (often insecure) Wide Area Network portion (shown as network180-2coupled to DA130and BA140) which may comprise part of the Internet and/or leased network links, and a third branch office portion (shown as network180-3coupled to BA140and clients160and170) which is typically a private network isolated from network portion180-2by a firewall. In such a branch office configuration, a plurality of clients (including client,160,170and others) are coupled to network180-3, each comprising a service equivalent to CCS162to facilitate connection to AS102or another application server, the application servers typically coupled to network180-1.

SG120is an optional server function, typically deployed in a perimeter region or Demilitarized Zone (DMZ) of network180. SG120ensures that network traffic flowing from client160to AS102meets authorization and authentication rules, including those configured by an administrator. In an embodiment, SG120operates as a proxy host for CM150in addition to providing proxy services for application data directed to AS102from outside the datacenter network. The SG120typically includes a configuration and control interface (e.g., a TCP socket) to allow an external connection manager such as CM150to enable and disable application sessions between clients and AS102. In some embodiments, SG120provides additional functions such as substituting the gateway domain name with specific domain names inside the trusted network and vice versa.

DA130and BA140are processing systems generally enabled to optimize network communications across network portion180-2, for example providing WAN acceleration functions (e.g., data compression and/or data caching) although in various embodiments, additional or alternative traffic manipulation services (such as traffic shaping functions, quality-of-service (QoS) functions, additional encryption functions, transport reliability functions, traffic policy functions, performance monitoring functions and the like) may be provided. In an embodiment, DA130and BA140each comprise a hardware processor sub-system (e.g., a CPU such as a XEON, x86, ARM or MIPS class processor) and memory resources enabled to execute machine readable software, including DA connection service (DACS)132in the case of DA130and BA connection service (BACS)142in the case of BA140. DA130and BA140may each comprise additional processing circuitry such as CPU and/or packet processing circuits enabled to manipulate network packets comprising graphics, audio and/or peripheral device data related to a remote computing session established between AS102and client160. Further, DA130and BA140may comprise TCP/IP and UDP/IP network protocol stacks, packet encryption/decryption services such as AES-128, AES-256 and/or SALSA-20 encryption/decryption services, security functions such as Secure Socket Layer (SSL) protocol stack and certificate management functions.

According to the present specification, DA130and BA140are each designated as “authorized” intermediary appliances by the explicit presence of DACS132and BACS142in DA130and BA140respectively. System100may comprise additional non-authorized intermediary appliances, such as legacy or incompatible branch- and datacenter-appliances without explicitly approved connection services.

While the embodiment of system100depicted inFIG. 1shows the paired intermediary appliance set DA130and BA140, alternative embodiments of system100comprise any combination of single or paired authorized intermediary appliances coupled to network180in the path between AS102and client160.

FIG. 2,FIG. 3andFIG. 4illustrate three alternative network topologies in which the intermediary appliance authentication method described herein enables selective authentication of authorized intermediary appliances.FIG. 2illustrates a network topology200in which SG120is configured between AS102and DA130such that datacenter network202is located behind SG120but corporate network204and private network206(between DA130and BA140) are outside the security perimeter. In such an embodiment, BA140might be attached to a private branch network208which is further coupled to client160.FIG. 3illustrates an alternative topology300in which SG120is configured between BA140and client160such that datacenter network302, private network304and private branch network306are located behind SG120(i.e., DA130is coupled to AS102by datacenter network302and to BA140by private network304, BA140is further coupled to SG120by private branch network306, and SG120is coupled to client160by network308). An example of such a topology is a network in which individual clients (e.g., telecommuters) connect across the internet to a remote office and the remote office has an optimized connection304between branch office and corporate network in a distant geographic location.FIG. 4illustrates another network topology400in which ‘N’ authorized intermediary appliances (shown as an authorized intermediary appliance402and an authorized intermediary appliance404) are configured between AS102and client160.

FIG. 5is a flowchart of a method500used to establish an authenticated communications path between client160and AS102that includes participation by a set of authorized intermediary appliances in accordance with one or more embodiments of the present invention. Method500starts at step502and proceeds to step504in which various apparatus of system100, including AS102, SG120, DA130, BA140, CM150and client160are each initialized and attached to network180, for example by registering with a reachable Domain Name Server (DNS), obtaining IP addresses and so on. While SG120is typically configured with an externally signed certificate, in different embodiments, SG120and/or AS102may be configured with ephemeral self-signed certificates generated, for example, by AS102or a trusted computer CM150. In an embodiment, the certificates generated for session establishment have a limited life to reduce exposure risk. DA130and/or BA140may be configured as Certificate Authorities (CA) or may be entrusted with the certificates of SG120if located in the trust domain of SG120.

Following initialization, method500proceeds with a pre-session initiator phase504comprising steps510and520. During phase504, authorized intermediary appliances DA130and BA140may provide generic switching or routing functions for TCP/IP communications between CCS162and servers such as AS102, but are not participants in SSL-secured communications. At step510(“Client Uses First Secure Channel (excluding intermediaries) to Initiate Connection Request”), CCS162establishes a first leg of a first channel typically with CM150or SG120(i.e., a trusted computer) although some embodiments may utilize AS102as the endpoint for pre-session initiation. In an embodiment, the first leg is an SSL-secured connection over TCP/IP, based on the verifiable certificate of the trusted computer. The connection request from CCS162is typically initiated when a user at client160wishes to access a service provided by AS102, for example by launching an application or web browser which prompts the user or retrieves stored address information (e.g., URL or FQDN) in order to initiate establishment of a secure channel with CM150or SG120. CM150contacts AS102following which a second leg of the first channel is established between AS102and CM150based on the verifiable certificate of CM150.

Method500proceeds to step520(“ASCS Provides Session Tags”) in which ASCS112generates a set of session tags comprising a first secret intended for later use by all participants of session initiator phase506and a second secret for exclusive use between ASCS112and client CCS162. The session tags are communicated to CCS162as one or more network payloads using the first secure channel and stored by both participants for subsequent use. An embodiment of such an exchange between ASCS112and CCS162is detailed in the method700described below.

Following a successful pre-session initiator phase504, method500proceeds with session initiator phase506which comprises steps530-570described below. If pre-session initiator phase504is unsuccessful, for example in cases where CM150is unreachable, client160may inform the user of the failed connection attempt. During the session initiator phase506, ASCS112uses the second secret to establish trust in a second secure channel between CCS162and ASCS112including authorized intermediary appliances, including signing a path description and negotiating a version to prevent either downgrade attacks or attempts by non-authorized intermediaries to join the path.

At step530(“Client and Intermediary Appliances Use Second Secure Channel to Send Versions, Client Portion Protected by Session Tags”), CCS162establishes the second secure channel with ASCS112, the second secure channel comprising a chain of secured connections (e.g., SSL over TCP/IP) inclusive of authorized intermediary appliances DA130and BA140. Subsequent to establishment of the second secure channel, CCS162initiates a version request in which participant version information (comprising device identity and optionally protocol and/or application version preferences) for the client and authorized intermediaries wishing to participate in pending application (APP) level communications, is compiled as a path description and forwarded to ASCS112by means of a suitable hello message protocol, for example cascaded APP_HELLO532over the second secure connection chain as detailed in the method900described below. In an embodiment, the path description is compiled as a series of eXtensible Markup Language (XML) stanzas wrapped in HTTP POST frames, commencing with the client version in XML format; to which each participating intermediary appends its own version information in XML format and communicates the modified XML message in the server facing direction of ASCS112.

As a next step540(“ASCS Sets Version and Signs Path Description, Protected by Session Tags”), an embodiment of which is detailed in step910of the method900described below, the ASCS112validates the version request to establish trust in the second secure channel by i) verifying information of the client computer presented by CCS162against separately held session tags (e.g., verifying a session identity presented in the client version information), ii) optionally selecting a protocol version (e.g., if multiple protocol versions are presented by one or more participants), and iii) signing the path description to prevent subsequent tampering. As a next step550(“Cascaded APP_VERSION Returns Negotiated Version along Described Path”), a cascaded APP_VERSION response (detailed in the method1000described below) is used to echo the negotiated version to the client160along the path comprising the intermediary appliances listed in the path description.

Method500proceeds to step560in which encryption capabilities are negotiated, and encryption keys and other session parameters related to a pending application session between AS102and client160are exchanged (between AS102and client160) over the second secure connection with the intermediary appliance DA130and BA140enabled to eavesdrop the exchange and retrieve pertinent session parameters. An embodiment of such an exchange of session parameters is detailed in the method1100described below.

Method500proceeds to step570in which the second secure connection between CCS162and ASCS112expires or is torn down. In an embodiment, the second secure connection expires before the initiation of encrypted communications between client160and AS102using a third secure channel secured and trusted using the encryption keys, shown as step580(“Encrypted Communications”) in which DA130and BA140are active participants. An example of such encrypted communications comprises IPSec Encapsulated Security Payload (ESP) secured UDP messages comprising media data exchanged as part of the application session, generally decrypted, processed and re-encrypted by DA130and BA140in a manner transparent to AS102or client160. In some embodiments, the second secure connection expires during or after such encrypted communications. For example, the second secure connection may be maintained so that a client can communicate operational instructions to a target authorized intermediary appliance in a secure manner, even after session parameters have been exchanged. Method500ends at step582(‘End’).

FIG. 6is a flowchart of a method600initiated by client160to request a connection with AS102in accordance with one or more embodiments of the present invention. Method600comprises steps executed by each of CCS162, CM150and ASCS112. Method600starts at step602and proceeds to step604in which CCS162initiates an SSL connection with CM150. Generally, CM150is accessed by establishing a connection with SG120and SG120provides proxy services to access CM150using a pre-assigned network socket. In the absence of a security gateway an SSL connection is established directly with CM150. In an embodiment, CCS162initializes an SSL software library (e.g., OpenSSL library), selects an SSL protocol version (e.g., SSLv2, SSLv3, TLSv1, or the like), initializes local SSL software structures and creates a TCP/IP socket for the server connection. CCS162sends a CLIENT_HELLO message to CM150to initiate an SSL connection.

Method600proceeds to step608(‘SSL Handshake with Client’) executed by CM150in which an SSL connection request from CCS162is detected and accepted by responding to the received CLIENT_HELLO with a SERVER_HELLO message. Step608continues in tandem with step612(‘SSL Handshake with CM’) executed by CCS162in which cryptographic keys are exchanged using SSL handshake methods known to the art (e.g. calling SSL_accept( ) on an SSL server (i.e., CM150) and SSL_connect( ) on the SSL client (i.e., client160)).

Following the SSL handshake at steps608/612, CCS162initiates user authentication over the SSL connection as step616by communicating user credentials to CM150. CM150responds at step620(‘Authenticate User and Identify Application’) by authenticating the user (e.g., authentication against credentials maintained in an Active Directory) and determining server-side connectivity requirements (e.g., in an embodiment, CM150selects a particular AS102and a particular ASCS (associated with a particular VDI desktop, hosted shared desktop or hosted application for example) based on the user credentials). CM150transmits a user connection request to the identified ASCS, such as ASCS112, as a next step624if user authentication passes at step622. If user authentication fails at step622, CM150denies the user connection request at step626, for example by notifying CCS162and terminating the SSL connection at step632.

Method600proceeds from step624to step628(‘Receive user connection request’) executed by ASCS112of AS102in which ASCS112receives a message from CM150requesting a connection associated with the designated and authenticated user. The method600then proceeds to step630where it ends.

FIG. 7is a flowchart of a method700in which session tags are provided to a client160in response to an authenticated user and in anticipation of a granted connection in accordance with one or more embodiments of the present invention. Method700is generally a continuation from conversation600ofFIG. 6. The method700begins at step702and proceeds to step704(‘Generate session tags’); in some embodiments where the method700is a continuation of the method600, step704is preceded by step628of the method600. In an embodiment, ASCS112generates a Session Identity (SID), e.g., in the form of a 64-bit random value which, when used in conjunction with per-session certificates, maintains a wide entropy in the session tags, thereby ensuring that legacy clients (e.g., clients utilizing legacy certificates) are nevertheless enabled for secure application sessions with AS102. The SID is algorithmically combined with the server certificate (to be associated with the same application session) as a ‘thumbprint hash value’ (alternatively termed a ‘thumbprint’ herein). An example of the generation and use of such a thumbprint is described by method1200ofFIG. 12described below. In addition to the thumbprint (i.e. the first secret of method500), the session tags comprise the SID and a nonce value that enables ASCS112and CCS162to share secrets during the session initiator phase506exclusive of any intermediary appliances. The SID, thumbprint and nonce together comprise the second secret of method500. In an embodiment, the nonce comprises a 64-bit random value which is stored by ASCS112and CCS162for the duration of the session initiator.

In some embodiments, the session tags further comprise additional connection information, such as a Fully Qualified Domain Name (FQDN) or other hostname for a particular host ASCS112), and/or encryption keys for scrambling data communicated during the session initiator phase.

The session tags are optionally passed to SG120at step708, to provide SG120with the connection information and/or provide SG120an opportunity to amend the session tags, e.g. substitution of FQDN or hostname. In an exemplary embodiment in which SG120maintains an externally signed certificate, SG120replaces the thumbprint hash value generated by ASCS112with a thumbprint hash value based on its own certificate and returns the amended session tags to ASCS112.

As a next step712, ASCS112grants a connection to the CCS162by communicating the session tags to the CM150. The CM150receives the session tags at step716and grants the CCS162a connection by communicating the session tags to the CCS162using the first secure channel. The CCS162receives the session tags from the CM150at step720.

On successful completion of the pre-session initiator phase504(i.e., successful completion of the methods600and700) in which CCS162received session tags from CM150, CCS162initiates the session initiator phase506and the method700proceeds from step720to step910of method900, where the method900is one embodiment of the method800described below. During the session initiator phase506, version information is communicated to ASCS112. The client version comprising SID (and optionally client protocol version and/or additional client capabilities) is signed using the session tags including the nonce (i.e., the second secret) and passed along the path of participating authorized intermediary appliances, each appending its own identity and/or version as additional version information to the path description. Intermediary appliances are not in possession of the nonce and are therefore unable to tamper with the client portion of the version information without detection by ASCS112.

FIG. 8is a flowchart of a method800for communicating client version information from a client802to a server804in accordance with one or more embodiments of the present invention. While client160assumes the role of ‘client802’ and BA140assumes the role of ‘server804’ for the initial segment of the session version request, the method800is repeated with BA140assuming the role of ‘client802’ and DA130assuming the role of ‘server804’ for the next segment of the session version request and so on down the line of additional intermediaries (if present) for additional segments of the session version request conversation. If any intermediary appliance is non-authorized, the designated client rejects it from the AS102‘server-facing’ communication path and attempts a session version request with the next server in line towards AS102(while maintaining previously established secure connections in the client160‘client facing’ direction), generally facilitated by the non-authorized intermediary appliance which is obliged to operate as a router between the client and the next server in the server-facing direction. Such a path including intermediaries is generally pre-configured using routing tables to direct traffic along determined network links through particular appliances and assumes the network180is physically wired accordingly. The client160typically addresses server entities (e.g., SG120, CM150or AS102) directly using appropriate server addresses (i.e., IP layer address designations) in which the intermediaries are transparent to the client from an IP addressing perspective.

Method800, comprising a first sequence of steps810(i.e., steps824,832,834, and836) executed by a client802and a second sequence of steps812(i.e., steps826,828,830,838, and840) executed by a server804, starts at step820and proceeds to step822in which a target server is determined, for example as determined by routing tables. If a previously determined server has been rejected, the rejected server generally operates as an IP router and the next server in the path toward AS102is selected. Method800then proceeds to step824in which client802sends an SSL CLIENT_HELLO message to server804determined at step822. In an embodiment, client802identifies CM150as the connection target by populating the Server Name Indication (SNI) field inherent in SSL protocol standards with the FQDN of CM150(or SG120if the connection manager is proxied). Alternatively, server name information is placed in another (typically ‘clear text’) pre-defined header field, to enable inspection by intermediaries.

Server804receives the SSL CLIENT_HELLO with SNI information at step826and retrieves an appropriate signed certificate at step828for valid SNI parameters (e.g., server804typically retrieves one from a selection of certificates related to a particular connection manager, such as the CM150, specified by the SNI parameter). If the SNI field is null or invalid, server804may i) operate as an IP switch or router (i.e., not intercept the message) or ii) retrieve a legacy certificate in different embodiments. The server804responds to client802by sending an SSL SERVER_HELLO message with the appropriate certificate at step830. Client802receives the SSL SERVER_HELLO message with the signed certificate from server804at step832and determines the certificate validity at step834. In some embodiments in which the client802maintains a certificate store, client802determines the validity and accepts the connection based on a presented name and a CA chain or in cases of an ephemerally signed certificate, it may be validated against the thumbprint hash value. In some embodiments, the client802executes a sequence of checks at step834in an attempt to confirm the signature until the certificate is either validated by one of the checks or eventually rejected by all the checks.

If the credentials are determined invalid at step834, client802may determine at step836to re-attempt an SSL SERVER_HELLO (i.e., repeat steps824and832). If the server804continues to send invalid certificates at step830(e.g., 5 iterations of step836in a typical embodiment) or if an extended time elapses without a server response (e.g., five seconds), client802proceeds to step860.

In an embodiment, step860comprises client802performing the steps of i) tearing down the SSL session ii) sending an SSL SESSION_REJECT message and iii) awaiting for a corresponding SSL SESSION_REJECTED message from server804. An authorized intermediary appliance is expected to respond to a rejection in such a manner, including allowing network traffic to pass through it following the SSL rejection (i.e., operating as a router). Following receipt of an SSL SESSION_REJECTED message from server804, client802typically returns to step822in which the next intermediary appliance down the line is selected as the server. Thereafter step824is repeated for the new server while maintaining any established SSL connections in the client-facing direction in a blocked state.

If the credentials satisfy the client802(i.e. the certificates succeed) at step834, an SSL session is established (ref. timeline850) and the client802sends an APP_HELLO with the SID and thumbprint hash value (received by the client at step720of the method700previously described) in addition to added version information in the SSL session at step836. The ‘added version information’ specifies either i) the client capabilities, for example comprising supported application protocol versions (e.g., type and/or version numbers of a remote computing protocol) in the embodiments where client802is the client160comprising client service CCS162or ii) intermediary appliance identity (e.g., a per-device identity assigned by a manufacturer) and optionally version information (e.g., appliance version and/or supported protocol versions) in the embodiments where the role of client802is executed by an authorized intermediary appliance.

As a next step838, the server804receives the APP_HELLO with SID, thumbprint hash value and the added version information and appends its own version information to the APP_HELLO stanza at step840. The method800then proceeds to step842where it ends.

If there are additional intermediary appliances in the path to AS102, the method800repeats with the server804then entering a client role (i.e., that of client802) and attempting to establish an SSL connection with the next server804in the path.

FIG. 9is a flowchart illustrating a method900in which version information for a client160and authorized chain of intermediary appliances (such as BA140and DA130) is communicated to ASCS112in accordance with one or more embodiments of the present invention. Method900is one embodiment of the method800described above and commences, following step720of method700, at step920.

At step910, CCS162performs the client role of communicating version information to a server (i.e., BACS142) as generally described for the sequence of steps810of method800. At step912, BACS142performs a server role of receiving version information from CCS162as generally described for the sequence of steps812of method800.

At step914, BACS142performs the client role of communicating version information with added BACS version information to a server (i.e., DACS132) as generally described for the sequence of steps810of method800. At step916, DACS132performs a server role of receiving version information with added BACS version from BACS142as generally described for the sequence of steps812of method800.

At step918, DACS132performs the client role of communicating version information with added BACS and DACS version information to a server (i.e., SG120) as generally described for the sequence of steps810of method800. At step920, SG120performs a server role of receiving version information (with added BACS and DACS version information) as generally described for the sequence of steps812of method800.

At step922, SG120performs the client role of communicating the accumulated version information (comprising the signed client portion and the appended BACS and DACS version information) to a server (i.e., ASCS112) as generally described for the sequence of steps810of method800. While the SG120may not necessarily contribute its own version information to the SESSION_HELLO stanza, it may replace the SNI of CM150with the SNI for ASCS112when initiating a CLIENT_HELLO (ref. step824of the method800). At step924, ASCS112performs a server role of receiving the accumulated version information as generally described for the sequence of steps812of method800.

At step926(‘Set Negotiated Version’), ASCS112determines the negotiated version by, at a minimum, verifying the SID presented as the client version, and optionally selecting an application/and or protocol version common to all participants (e.g., the highest common protocol version in a typical embodiment) in the chain and prepares an APP_VERSION response stanza comprising i) a path description which comprises the list of versions for all authorized participants, and ii) the negotiated version. The path description is signed with the session tags (i.e., the second secret) to prevent intermediary appliances being added or withdrawn from the path. In an embodiment, the negotiated version is also signed to prevent a malicious downgrade attack by an intermediary appliance. The method900then proceeds to step1010of method1000, described below.

FIG. 10is a flowchart illustrating a method1000in which the negotiated version and signed path description determined at step910is communicated from AS102back to the client160in accordance with one or more embodiments of the present invention. Method1000and commences, following step926of the method900, at step1010(‘Send APP_VERSION’) in which the negotiated version and signed path description is sent from ASCS112to SG120.

At step1012, the SG120receives the APP_VERSION message and forwards it to the DACS132. At step1014, the DACS132receives the APP_VERSION message and forwards it to the BACS142. At step1016, the BACS142receives the APP_VERSION message and forwards it to the CCS162. Each authorized intermediary appliance generally retains a copy of the negotiated version for reference in subsequent processing decisions.

At step1018, the CCS162receives the negotiated version and path description, verifies the presence and validity of the returned signature by parsing the XML that describes the path description, and prepares for an exchange of encryption keys if the negotiated version specified at step910is accepted. If any of the version stanzas in the path description comprise mistrustful data (e.g., a modified version for a particular appliance), the signature communicated at step1010is determined by the CCS162as not matching the path description and the CCS162typically closes the SSL socket. In some embodiments, client162utilizes the APP_VERSION path description stanza to index authorized intermediary appliances for future communications such as configuring operational settings of a particular appliance directly. In one embodiment, each authorized intermediary appliance is assigned an index based on the position of the intermediary appliance in the chain as determined by parsing the APP_VERSION path description XML stanza. Control parameters are passed to a particular intermediary appliance utilizing the index in subsequent XML communication stanzas. In another embodiment, intermediary appliances append addressing information such as IP address, port number, encryption keys and/or protocol specification by which client162may contact the authorized intermediary appliance out of band at a subsequent time.

FIG. 11is a flowchart illustrating a method1100in which, in accordance with one or more embodiments of the present invention, the client160initiates a process with the AS102in order for an encryption version (e.g., AES-128-GCM or AES-256-GCM) to be negotiated, associated encryption keys to be exchanged, and optionally additional setup parameters associated with a pending application session to be negotiated. Method1100commences, following step1018of method1000, at step1102(‘Client INVITE’) in which CCS162sends an INVITE message to ASCS112via the existing chain of ‘N’ authorized intermediary appliance connection services (shown as nAIACS1150, for example comprising BACS142chained with DACS132) and SG120. The INVITE message contains the encryption capabilities that CCS162is willing to use.

At step1104, each authorized intermediary appliance of nAIACS1150forwards the INVITE message to the next authorized intermediary appliance in the chain (e.g., BACS142forwards the message to DACS132), and the final authorized intermediary appliance in the chain (e.g., DACS132) forwards the INVITE message to SG120, taking note of parameters associated with each of the encryption capabilities advertised by the client until confirmation of negotiated cipher and key sets in the subsequent INVITE OK. If the INVITE message does not contain any expected encryption capabilities, nAIACS1150(i.e., BACS142and DACS132as depicted inFIG. 1) is expected to allow the session to continue normally and act as a router for traffic in both directions. At step1106SG120forwards the INVITE message to ASCS112.

ASCS112processes the INVITE message at step1110by first confirming the SID in the INVITE message matches the SID on record. If not, ASCS112may respond to the INVITE with an UNACCEPTABLE message and the session will be terminated. When the SID is confirmed, ASCS112determines which encryption algorithm shall be used and responds to the received INVITE with an INVITE OK message to the SG120that points nAIACS1150to relevant parameters from the previous INVITE message as well as parameters that will be used for messages from ASCS112. At step1112, SG120parses the INVITE OK and forwards it to nAIACS1150. At step1114, nAIACS1150parses the INVITE OK and forwards it to CCS162(i.e., as depicted inFIG. 1, the DACS132parses the INVITE OK and forwards it to BACS142, which parses the INVITE OK and forward it to CCS162). If any participant receives a garbage or out of order message, the participant generally closes the SSL connection and abandons the session. At step1120the CCS162receives the INVITE OK and accepts the negotiated encryption algorithm and parameters.

As a next step1130(comprising1130-1‘Negotiate Setup’ for CCS162,1130-2‘Eavesdrop Negotiation’ for nAIACS1150,1130-3‘Negotiate Setup’ for SG120, and1130-4‘Negotiate Setup’ for ASCS112), setup information is exchanged between ASCS112, SG120and CCS162, including encryption keys (e.g., UDP encryption keys) utilized for encrypting data related to the pending application session. Additionally, nAIACS1150may monitor the setup and control data exchanged between SC120and CCS162, and in particular retain encryption keys. nAIACS1150use the keys to intercept, decode, process and re-encode data associated with the application session as determined by the capabilities of the authorized intermediary appliance(s), either following the completion of key exchanges (ref. steps1130and step1132) or after the SSL connection has terminated. In some embodiments, the SSL connection remains active for a determined period following the exchange of keys. As a next step1140(shown as1140-1,1140-2,1140-3and1140-4‘Terminate SSL’ for CCS162, nAIACS1150, SG120and ASCS112, respectively), the SSL connection is torn down once the exchange of setup and control information has completed. The method1100then proceeds to step1150where it ends.

FIG. 12is a flowchart illustrating a method1200, in accordance with one or more embodiments of the present invention, executed by an ASCS112and a CCS162which enables authentication without burdening the client160with a traditional certificate validation process. Method1200starts at1202and proceeds to step1204in which ASCS112retrieves a signed and typically public certificate. As a next step1206, ASCS112generates a random SID such as random 64-bit number. A thumbprint hash value is then derived from a combination of the SID and the certificate. In one embodiment, the SID is concatenated with the certificate and the resultant concatenation hashed using a Secure Hash Algorithm (SHA) such as a SHA-256 hash to generate a thumbprint hash value. In another embodiment, the SID is itself hashed (e.g. using a SHA-256 hash) prior to concatenation with the certificate, followed by a second hashing function to generate the thumbprint hash value; thereby enabling authorized intermediaries to generate thumbprint hash values without possession of the SID.

As a next step1208, the thumbprint hash value generated at step1206is sent to the CCS162as part of the session tags (ref. step712of the method700). CCS162receives the session tags at step1210and stores the server thumbprint hash value and SID for subsequent certificate validation. As previously described with respect to the method500, the session tags further comprise a nonce used for trusted data exchanges between ASCS112and CCS162, excluding authorized intermediaries.

The method1200proceeds to step1220in which ASCS112presents a certificate to CCS162for validation. In some embodiments, step1220may be part of step1110of the method1110. CCS162receives the certificate at step1222(e.g., correlating with step1120in method1100) and at step1224, generates a second thumbprint hash value by concatenating the presented certificate with the SID stored at step1210.

As a next step1226, CCS162determines the validity of the presented certificate by comparing the second thumbprint hash value generated at step1224with the server thumbprint hash value stored at step1210. The presented certificate is validated by matching thumbprint values. If the presented certificate is validated, trust in the server is established (for example an SSL session setup is completed (ref timeline850in method800)). If the presented certificate is determined to be invalid, any pending SSL connection is typically torn down and the server rejected (ref. step860in method800). Method1200then ends at step1240. In some embodiments, the thumbprint hash value provided in the session tags is generated by SG120rather than ASCS112.

FIG. 13is a flowchart illustrating a method1300, in accordance with one or more embodiments of the present invention, executed by an ASCS112for establishing encrypted communications. Method1300starts at step1302and proceeds to step1304in which two secrets are generated from a certificate, for example the session tags generated by ASCS112at step704of method700. In an embodiment, the certificate is a self-signed certificate generated by AS102and is untraceable to any CA. In an embodiment, the first secret comprises a thumbprint determined as a hashed combination of the certificate, and a cryptographically random session identifier (SID); the first secret intended for sharing between the client160and the AS102inclusive of one or more authorized intermediary appliances and the second secret comprises the thumbprint, the SID and a nonce, the second secret intended for sharing between the client160and the AS102exclusive of the authorized intermediary appliances.

As a next step1306, the secrets are transmitted from AS102to client106over a previously established first channel secured and trusted based on a trusted computer CM150, for example as sent from ASCS112to CCS162using steps712,716and720of method700. The trusted computer CM150is trusted by AS102and client160based on a verifiable certificate of the trusted computer CM150. In an embodiment, a first leg of the first channel is established between client160and CM150based on a verifiable certificate of the trusted computer CM150and a second leg of the first channel is established between the AS102and the CM150based on the verifiable certificate. The trusted computer CM150routes payloads comprising the first and second secrets between the AS102and client160(i.e. between the first leg and the second leg). As an example, the secrets are generated and transmitted in response to a request, received via the first leg of the first channel, to establish a second secure and trusted channel between client160and AS102; i.e., (i) the first channel is established by the AS102addressing first communications to the trusted computer CM150and the client160addressing second communications to the trusted computer, and (ii) the second channel is established by the client160addressing third communications to the AS102.

As a next step1308, in response to a secure channel request from an authorized intermediary appliance (ref. DA130), AS102presents the certificate to the DA130. In some embodiments such as steps922and924of method900, the certificate is presented to SG120which has previously established a secure channel with DA130at steps918and920of method900. In an embodiment, the secure channel request is a Secure Socket Layer (SSL) cryptographic protocol hello request over a reliable transport layer such as TCP/IP. The DA130determines a trustworthiness of the sever AS102based on the certificate and the first secret held by the DA130. Presenting the certificate to the DA130enables DA130to determine the trustworthiness of AS102based on first secret.

As a next step1310, an embodiment of which is depicted at step924of method900, AS102receives a description of a second channel from the DA130located between AS102and client160. The description of the second channel comprises (i) a path description which has been amended by, is visible to, and identifies at least one authorized intermediary appliance in a path of the second channel (i.e., the path describing DA130and optionally additional authorized intermediary appliances on the path between the client160and AS102), and (ii) client information such as a SID or combination of SID and thumbprint from the client160signed by the second secret. The AS102establishes trust in the second channel by having the second secret and client information signed by the second secret.

As a next step1312, channel information is transmitted via the second channel from AS102to client160once AS102has established trust in the second channel, for example as illustrated by steps1010,1012,1014,1016and1018of method1000. The channel information comprises at least a portion of the path description signed by the second secret which enables the client160to determine trustworthiness of the second channel. The portion of the path description signed by the second secret identifies a trustworthiness of the second channel to the client160. The path description is verifiable by the client160based on the portion of the description signed by the second secret. Generally, step1312further comprises transmitting a protocol version usable in further communications on the second channel. The protocol version typically comprises a most recent protocol version compatible with the AS102, client160and the authorized intermediary appliance.

As a next step1314, encryption keys are shared and encrypted communications established compliant with a protocol version identified in the description of the second channel (i.e., the negotiated version set at step926of method900) and the encryption algorithm version determined at step1110of method1100. The AS102(i) shares encryption keys with the client160, the DA130and the BA140over the second channel, (ii) a third channel is established, secured and trusted based on the encryption keys and (iii) media data is communicated via the third channel as unreliable datagrams between AS102and the client160using the same 4-tuple network addresses scheme as the second channel.

FIG. 14is a flowchart illustrating a method1400, in accordance with one or more embodiments of the present invention, executed by CCS162for establishing encrypted communications. Method1400starts at step1402and proceeds to step1404in which CCS162receives an address for AS102in addition to first and second secrets from AS102via a trusted computer CM150utilizing a first secure and trusted channel, for example as previously described for pre-session initiator phase504of method500. The first secret is usable by an authorized intermediary appliance such as DA130to establish trust in AS102subsequent to AS102presenting the certificate to the authorized intermediary appliance that was originally used to generate the first secret.

As a next step1406, CCS162initiates a second secure channel with AS102, comprising transmitting a packet addressed with the address for AS102, for example using an SSL client hello as described for step824of method800. As a next step1408, the CCS162establishes trust in a first leg of the second secure channel based on a verifiable certificate presented by an authorized intermediary appliance BA140. In an embodiment previously described, server804presents a certificate at step830of method800and trust is established at step834based on the certificate validity. As a next step1410, the CCS162shares the first secret and information of the client computer signed by the second secret, with the authorized intermediary appliance for example by sending APP_HELLO at step836. The information of the client computer comprises data verifiable by AS102as originating from CCS162and in an embodiment, comprises the SHA-256 hash resultant concatenation of the SID, the thumbprint hash value and server address requested by the client. As a next step1412, the CCS162establishes the trust of the second secure channel based on receiving, via the second secure channel, a path description of the second secure channel signed by the second secret which identifies the authorized intermediary appliance BA140. As a next step1414, CCS162receives encryption keys and establishes encrypted communications with AS102, including BA140and DA130. Method1400ends at step1420.

FIG. 15is a flowchart illustrating a method1500, in accordance with one or more embodiments of the present invention, executed by an intermediary appliance such as DA130or a BA140, for establishing encrypted communications. In some embodiments in which authorized intermediary appliances operate in tandem, only one of the appliances need partake in appending information to the path description, establishing trust with AS102and subsequent eavesdropping on the exchange of encryption keys. Thereafter, the participant appliance may utilize a private channel to forward encryption keys and version information to its tandem appliance(s).

Method1500starts at step1502and proceeds to step1504in which BA140obtains address information (such as server address) from a client160for identifying packets routed through BA140but addressed to AS102. For example, BA140operating in capacity of server804receives an SSL client hello with SNI at step826in method800. In response to receiving a request for a first secure BA channel from client160addressed to AS102(and identifiably by the address information), BA140presents a certificate verifying it as an authorized intermediary appliance, for example as shown at step830in method800. As a next step1506, BA140receives via the first secure BA channel, from client160, (i) a first secret usable in authenticating AS102and (ii) a path description identifying the client160. As a next step1508, the BA140appends its own identification information to the path description. As a next step1510, the BA140establishes a secure and trusted channel with the next authorized appliance in the direction of AS102(i.e., DA130) or with AS102itself in different embodiments in order to transmit the appended path description to the server (i.e., BA140performs the role of client802in a repeated method800). The trust of the second secure BA channel is based on using the first secret to validate a certificate presented by DA130or AS102in different embodiments. As a next step1512, the negotiated and signed path description (i.e., payload) from AS102is echoed by BA140to client160using previously established first and second secure BA channels.

As a next step1514, BA140eavesdrops the exchange of encryption keys. Thereafter, BA140establishes a private channel with DA130in the path between client160and AS102. As a next step1516, the DA130and BA140jointly perform data compression/decompression tasks, for example DA130decrypts media data received from AS102, compresses the media data and communicates the compressed media data as encoded data to BA140over the established private channel. BA140decompresses and re-encrypts the encoded media data (i.e., regenerates the original data) prior to forwarding it on to client160. In an embodiment, BA140establishes a third trusted BA channel with client160and a fourth trusted BA channel with AS102based on encryption keys exchanged, via the first secure BA channel and the second secure BA channel, between AS102and the client160. The first and second secure BA channels use a reliable transport protocol whereas the third and fourth trusted BA channels use an unreliable datagram protocol. The method1500proceeds to step1520where it ends.