Proxy Token Mechanism for TLS Session Resumption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Non-terminating TLS proxies in network security systems lack a mechanism to efficiently recognize returning clients who have previously passed security checks, leading to inefficient processing of traffic and preventing the site protection layer from scaling well, as they must repeat security checks every time a client reconnects.
Innovation Solution
Implementing a 'proxy token' system where the proxy server performs initial security checks on an unknown client, transmits the token to the origin server, which stores it in session state data, allowing the proxy to bypass checks upon successful validation during session resumption, thereby expediting the handling of known clients.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a non-terminating TLS proxy performs security checks on every client connection, then security is maintained, but processing efficiency deteriorates and scalability is prevented
Solution Approach 1:
The proxy server performs security checks in advance during the initial TLS handshake phase. By completing these checks before the main data transfer begins, the system establishes security clearance status that can be referenced during subsequent connections, avoiding repetitive checks and improving processing efficiency while maintaining security.
Solution Approach 2:
The proxy server uses feedback from the TLS handshake process to determine client identity and security clearance status. Information exchanged during the handshake (such as client certificates, fingerprints, or other identifying parameters) is used to create a feedback loop where the proxy can recognize returning clients and apply different processing paths based on their established status.
2Reliability
If a non-terminating TLS proxy repeats security checks for returning clients, then security is maintained, but processing time increases
Solution Approach 1:
Security verification is performed preliminarily during the initial connection establishment phase. The proxy server completes security checks and establishes client identity before the main data transfer begins, so that returning clients can benefit from pre-verified status and avoid repeated time-consuming security checks.
Solution Approach 2:
The proxy server creates a copy or representation of the client's security clearance status and identity information that can be stored and referenced. This copy allows the proxy to recognize returning clients without requiring them to undergo the full security check process again, reducing processing time while maintaining security through the copied verification state.
3Object-affected harmful factors
If a non-terminating TLS proxy performs deep packet inspection and security checks, then threat protection is improved, but system scalability deteriorates
Solution Approach 1:
The proxy server performs threat detection and security checks in advance during the connection establishment phase rather than continuously during data transfer. By completing these operations preliminarily, the system can scale better because returning clients don't trigger repeated deep packet inspection, while still maintaining thorough threat protection through initial verification.
Solution Approach 2:
The proxy server extracts and separates the security verification function from the ongoing data transfer process. By taking out the security checks to the preliminary connection phase, the system can handle more concurrent connections and scale better, while maintaining threat protection through the extracted verification mechanism that operates independently of the data transfer volume.
Data Source
AI summary
This document describes, among other things, systems and methods for more efficiently resuming a client-to-origin TLS session through a proxy layer that fronts the origin in order to provide network security services. At the time of an initial TLS handshake with an unknown client, for example, the proxy can perform a set of security checks. If the client passes the checks, the proxy can transmit a ‘proxy token’ upstream to the origin. The origin can incorporate this token into session state data which is passed back to and stored on the client, e.g., using a TLS session ticket extension field, pre-shared key extension field, or other field. On TLS session resumption, when the client sends the session state data, the proxy can recover its proxy token from the session state data, and upon successful validation, bypass security checks that it would otherwise perform against the client, thereby more efficiently handling known clients.