Distributed TLS Registry for Replay Attack Detection
Find Innovative SolutionsGenerate 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
Engineering 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
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.
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.
2Reliability
If request records are maintained across multiple devices with distributed registry, then comprehensive replay detection is improved, but communication overhead between devices increases
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.
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.
3Productivity
If a mapping function is used to distribute request ownership, then request routing efficiency is improved, but system complexity increases
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.
Data Source
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.


