Split Proxy SSL Key Isolation via Intermediary Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing data communication networks face challenges in securely transmitting data across multiple intermediaries without exposing encryption keys, leading to potential security vulnerabilities in SSL communications.
Innovation Solution
Implementing a method and system for split proxying SSL communications across intermediaries, where each secure connection is assigned a unique encryption key, ensuring that data is encrypted and decrypted using the corresponding key within each connection, thereby isolating key usage and preventing exposure across proxies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If encryption key information is shared across intermediaries to enable SSL communications, then secure connections can be established between clients and servers, but security vulnerabilities arise due to potential key exposure across multiple proxies
Solution Approach 1:
The patent segments the encryption key management by assigning a unique encryption key to each secure connection between intermediaries. Instead of sharing a single key across all proxies, each connection (e.g., client-to-proxy1, proxy1-to-proxy2, proxy2-to-server) has its own isolated key. This segmentation prevents key exposure across the entire proxy chain, as compromising one connection's key does not affect other connections.
Solution Approach 2:
The patent introduces intermediary entities (proxies) that facilitate secure communication without requiring direct key sharing between end points. Each intermediary establishes its own secure connection with adjacent entities using unique keys, acting as a mediator that isolates key management. The intermediaries enable SSL communications while maintaining security boundaries through their key isolation architecture.
2Reliability
If multiple intermediaries are deployed to relay communications, then data acceleration and shielding protection are provided, but the complexity of managing secure connections increases
Solution Approach 1:
The patent simplifies multi-intermediary management by segmenting key management into independent connection-specific keys. Each intermediary only needs to manage its own unique key for its incoming connection and a different unique key for its outgoing connection, rather than managing shared keys with all other intermediaries. This reduces the computational and administrative complexity of key management in multi-proxy architectures.
3Ease of operation
If a single encryption key is used across all secure connections, then key management is simplified, but security is compromised due to potential exposure across all connections
Solution Approach 1:
The patent resolves this contradiction by segmenting the encryption key space into multiple connection-specific keys. While this increases the number of keys from one to many, it actually simplifies key management operations because each key is isolated to a single connection. This eliminates the need for complex key rotation and revocation procedures across all connections, as compromising or managing one key does not affect others.
Solution Approach 2:
The patent applies local quality by making each encryption key locally specific to its connection rather than globally shared. Each connection has its own key properties and security characteristics, allowing for localized key management, rotation, and revocation. This localizes security operations and makes the system more manageable despite having multiple keys.
Data Source
Figure 1A
Figure 1B
Figure 1C
AI summary
The present invention is directed towards systems and methods for split proxying Secure Socket Layer (SSL) communications via intermediaries deployed between a client and a server. The method includes establishing, by a server-side intermediary, a SSL session with a server. A client-side intermediary may establish a second SSL session with a client using SSL configuration information received from the server-side intermediary. Both intermediaries may communicate via a third SSL session. The server-side intermediary may decrypt data received from the server using the first SSL session's session key. The server-side intermediary may transmit to the client-side intermediary, via the third SSL session, data encrypted using the third SSL session's session key. The client-side intermediary may decrypt the encrypted data using the third SSL session's session key. The client-side intermediary may transmit to the client the data encrypted using the second SSL session's session key.