TLS Session Ticket Tracking for Cookie-Blocked User Sessions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing server-side application layer user session tracking methods face challenges due to browser cookie blocking and the complexity of non-HTTP protocols, which lack ubiquity and increase system complexity.
Innovation Solution
Leveraging the TLS ticket mechanism to convey an identifier for application layer session tracking, either through a one-way hash of the session key or a randomly generated identifier, allowing session resumption and data association without requiring server-side state.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If cookies are used for application layer user session tracking, then session tracking can be implemented, but browser cookie blocking causes tracking failure
Solution Approach 1:
The patent uses TLS session tickets as an intermediary mechanism to transfer session identifiers. Instead of relying on cookies that can be blocked by browsers, the session identifier is embedded within the TLS protocol's session resumption mechanism, allowing tracking to occur at the transport layer where it cannot be blocked by application layer policies.
Solution Approach 2:
The patent replaces the cookie-based tracking mechanism (application layer) with a TLS session ticket-based mechanism (transport layer). This substitution moves the tracking functionality to a lower protocol layer where browser security policies do not interfere, effectively replacing a blocked mechanism with an unblocked alternative.
2Object-affected harmful factors
If non-HTTP protocols like WebSockets or RDP are used for session tracking, then cookie blocking is avoided, but system complexity increases
Solution Approach 1:
The patent makes the TLS session ticket mechanism serve dual purposes: both TLS session resumption (original function) and application layer session tracking (new function). By embedding the application session identifier within the TLS session ticket, a single protocol mechanism accomplishes both security resumption and tracking, eliminating the need for separate non-HTTP protocols.
Solution Approach 2:
The patent merges the session tracking functionality with the TLS session resumption mechanism. The application session identifier is combined with the TLS session state and encrypted together in the session ticket, creating a unified mechanism that achieves both session recovery and tracking without requiring separate protocol infrastructure.
3Measurement precision
If server-side state is maintained for session tracking, then tracking accuracy is improved, but server resource consumption increases
Solution Approach 1:
The patent extracts the session tracking identifier from the server-side state and places it within the client-held TLS session ticket. The server only maintains minimal ticket verification state rather than full session information, reducing server memory requirements while preserving tracking accuracy through the embedded identifier in the client-provided ticket.
Solution Approach 2:
The client carries its own session tracking identifier within the TLS session ticket, eliminating the need for the server to store and manage extensive session state. The ticket itself serves as a self-contained credential that proves session identity without requiring proportional server-side storage resources.
Data Source
AI summary
This disclosure provides for server-side application layer session tracking by leveraging the TLS ticket mechanism. Assuming a client indicates support for a TLS ticket when establishing a transport layer session, a server creates a TLS ticket for the transport layer session and conveys in the TLS ticket to the client an identifier used for application layer session tracking. When the client resumes a transport layer session with the TLS ticket, a server extracts from the TLS ticket the identifier and indicates or makes available the identifier application layer session tracking.


