Citrix Systems, Inc.

Tushar Kanekar

Sivaprasad R Udupa

Ashoke Saha

Christofer Edstrom

Andrew Penner

Abhishek Chauhan

Josephine Suganthi

Rajesh Joshi

Swarupa Gonuguntla

Tejus Ag

Sandeep Kamath

Robert Kidd

Sandhya Gopinath

Mahesh Arumugam

Harpreet Singh

Sergey Golubev

Sikha Gopinath

Ritesh Patani

Systems and methods for detecting attacks using a handshake request are provided. A plurality of devices can receive a plurality of handshake requests to establish TLS connections that include a respective application request. At least one of the plurality of handshake requests can include a first application request. The plurality of devices can record each of the respective application requests to a registry of application requests. A first device of the plurality of devices can receive a subsequent handshake request to establish a subsequent TLS connection that includes the first application request. The first device can query, prior to accepting the first application request, the registry for the first application request. The first device can determine whether to accept or reject the first application request responsive to identifying from the query that the first application request has not been or has been recorded in the registry.

Detecting attacks using handshake requests systems and methods

Systems and methods for applying an application layer policy to a transport layer security request are provided. A device, intermediary to one or more clients and one or more servers, can receive a transport layer security (TLS) request to establish a TLS connection between a client of the one or more clients and a server of the one or more servers. The TLS request can include an application layer request to a resource of the server. The device can apply an application layer policy to the application layer request of the TLS request. The device can determine, responsive to applying the application layer policy, whether to one of accept or reject at least the application layer request of the TLS request.

Applying application layer policy to transport layer security requests systems and methods

The present disclosure is directed towards systems and methods for executing cryptographic operations across different types of processing hardware. An intermediary device may identify a cryptographic function to be performed at the device, according to a message from a client or a server. The device may identify a sequence of cryptographic operations to be executed for performing the cryptographic function. The device may determine subsets of the cryptographic operations to be executed on across different types of processing hardware. The different types of processing hardware may reside on the device. Each of the types of processing hardware may execute, responsive to the determination, the respective subset of the cryptographic operations, according to the sequence of the cryptographic operations.

Systems and methods for executing cryptographic operations across different types of processing hardware

The present invention is directed towards systems and methods for managing SSL session persistence and reuse in a multi-core system. A first core may indicate that an SSL session established by the first core is non-resumable. Responsive to the indication, the core may set an indicator at a location in memory accessible by each core of the multi-core system, the indicator indicating that the SSL session is non-resumable. A second core of the multi-core system may receive a request to reuse the SSL session. The request may include a session identifier of the SSL session. In addition, the session identifier may identify the first core as an establisher of the SSL session. The second core can identify from encoding of the session identifier whether the second core is not the establisher of the SSL session. Responsive to the identification, the second core may determine whether to resume the SSL session.

Systems and methods for encoding the core identifier in the session identifier

The present invention is directed towards systems and methods for managing one or more SSL sessions. A first node from a cluster of nodes intermediary between a client and a server may receive a first request from the client to use a first session established with the server. The first request may include a session identifier of the first session. The first node may determine that the first session is not identified in a cache of the first node. The first node may identify, via a hash table responsive to the determination, an owner node of the first session from the cluster using a key. The key may be determined based on the session identifier. The first node may send a second request to the identified owner node for session data of the first session. The session data may be for establishing a second session with the server.

Systems and methods for SSL session management in a cluster system

The present application is directed towards using a distributed hash table to track the use of resources and/or maintain the persistency of resources across the plurality of nodes in the multi-node system. More specifically, the systems and methods can maintain the persistency of resources across the plurality of nodes by the use of a global table. A global table may be maintained on each node. Each node's global table enables efficient storage and retrieval of distributed hash table entries. Each global table may contain a linked list of the cached distributed hash table entries that are currently stored on a node.

Systems and methods for reliable replication of an application-state, distributed replication table

The present invention is directed towards systems and methods for distributed operation of a plurality of cryptographic cards in a multi-core system. In various embodiments, a plurality of cryptographic cards providing encryption/decryption resources are assigned to a plurality of packet processing engines in operation on a multi-core processing system. One or more cryptographic cards can be configured with a plurality of hardware or software queues. The plurality of queues can be assigned to plural packet processing engines so that the plural packet processing engines share cryptographic services of a cryptographic card having multiple queues. In some embodiments, all cryptographic cards are configured with multiple queues which are assigned to the plurality of packet processing engines configured for encryption operation.

Systems and methods for queue level SSL card mapping to multi-core packet engine

Systems and methods for handling SSL session not reusable across multiple cores

Systems and methods are disclosed for an appliance to authenticate access of a client to a protected directory on a server via a connection, such as a secure SSL connection, established by the appliance. A method comprises the steps of: receiving, by an appliance, a first request from a client on a first network to access a server on a second network, the appliance providing the client a virtual private network connection from the first network to the second network; determining, by the appliance, the first request comprises access to a protected directory of the server; associating, by the appliance, an authentication policy with the protected directory, the authentication policy specifying an action to authenticate the client's access to the protected directory; and transmitting, by the appliance in response to the authentication policy, a second request to the client for an authentication certificate. Corresponding systems are also disclosed.

Systems and methods for policy based triggering of client-authentication at directory level granularity

The present invention is directed towards systems and methods for batching OCSP requests and caching corresponding responses. An intermediary between a plurality of clients and one or more servers receives a first client certificate during a first SSL handshake with a first client and a second client certificate during a second SSL handshake with a second client. The intermediary may identify that the statuses of the client certificates are not in a cache of the intermediary. An OCSP responder of the intermediary may transmit a single request to an OCSP server to determine the statuses. The intermediary may determine, from a single response received from the OCSP server, whether to establish SSL connections with the clients based on the statuses. The intermediary may store the statuses to the cache for determining whether to establish a SSL connection in response to receiving a client certificate from the first client.

Systems and methods for flash crowd control and batching OCSP requests via online certificate status protocol

The present disclosure is directed towards systems and methods for determining a status of a client certificate from a plurality of responses for an Online Certificate Status Protocol (OCSP) request. An intermediary device between a plurality of clients and one or more servers identifies a plurality of OCSP responders for determining a status of a client certificate responsive to receiving the client certificate from a client during a Secure Socket Layer (SSL) handshake. Each of the plurality of OCSP responders may transmit a request for the status of the client certificate to a uniform resource locator corresponding to each OCSP responder. The intermediary device may determine a single status for the client certificate from a plurality of statuses of the client certificate received via responses from each uniform resource locator.

Systems and methods for evaluating and prioritizing responses from multiple OCSP responders

This disclosure is directed to systems and methods for handling the processing of a next protocol negotiation extension for a transport layer security (TLS) session. A device, intermediary to a client and a server, may receive a client hello message from the client in a handshake to establish a transport layer security (TLS) session with the server. The client hello message may include a next protocol negotiation extension. The device may include a first TLS processor that is software based and a second TLS processor that is hardware based. The device may determine that the client hello message includes the next protocol negotiation extension. The device may establish, responsive to the determination, the TLS session using the first TLS processor. The device may process, upon establishment of the TLS session using the first TLS processor, encrypted data for the TLS session using the second TLS processor.

Growing community of inventors

Santa Clara, CA, United States of America

Tushar Kanekar