Distributed TLS Registry for Replay Attack Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Server deployments face challenges in distinguishing between original and repeated client requests, particularly in replay attacks where malicious actors resend identical requests, leading to difficulties in determining which requests have been previously processed, and existing protocols often lack sufficient protection against such network attacks.

Innovation Solution

Implementing a system of devices, such as TLS servers, that maintain a distributed registry of received requests across multiple devices, allowing them to identify and prevent replay attacks by querying each other to determine if a request has been previously recorded before processing it, using a mapping function to distribute request ownership and maintain records until an expiration period.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a distributed registry system is implemented across multiple devices to track requests, then replay attack detection capability is improved, but device complexity and communication overhead increase

Engineering Contradiction:
Improvereplay attack detection capabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The registry is divided into multiple distributed subsets across different devices in the cluster. Each device maintains a portion of the registry (registry subset) rather than a single centralized registry, which distributes the storage and query load while maintaining collective replay detection capability across the entire system.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A mapping function acts as an intermediary mechanism that receives a request identifier and determines which specific device in the cluster should handle the registry query for that request. This mediator function simplifies the complexity by providing a deterministic rule for request routing without requiring direct peer-to-peer communication between all device pairs.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If request records are maintained across multiple devices with distributed registry, then comprehensive replay detection is improved, but communication overhead between devices increases

Engineering Contradiction:
Improvecomprehensive replay detectionVSAvoidcommunication overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The mapping function is pre-configured with the registry distribution scheme, allowing devices to determine the destination device for any given request identifier without requiring real-time coordination or communication with other devices. This preliminary setup eliminates the need for dynamic discovery or negotiation during request processing.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Each device independently executes the mapping function using the request identifier to determine which device should handle the registry query. This self-service approach allows devices to autonomously route their own queries without requiring centralized coordination or iterative communication, reducing overall system communication overhead.

Inventive Principle:
Principle #25Self-service

3Productivity

If a mapping function is used to distribute request ownership, then request routing efficiency is improved, but system complexity increases

Engineering Contradiction:
Improverequest routing efficiencyVSAvoidrouting logic complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The mapping function transforms the request identifier (a potentially complex, high-dimensional parameter) into a simplified device identifier through a deterministic mathematical transformation. This parameter change converts an ambiguous routing problem into a precise, computationally efficient lookup operation that can be executed locally without complex routing logic.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12192237B2Detecting attacks using handshake requests systems and methods
Publication Date: 2025.01.07 CITRIX SYSTEMS INC
  • US12192237B2 patent drawing
  • US12192237B2 patent drawing
  • US12192237B2 patent drawing

AI summary

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.