HTTPS Proxy Using mTLS for Secure User Identification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The use of explicit HTTP proxy introduces security concerns and port limitations when accessing destinations from remote locations, particularly in guest Wi-Fi environments, due to the need for non-standard ports and decryption of TLS traffic for user identification.
Innovation Solution
Implementing a Hypertext Transfer Protocol Secure (HTTPS) proxy service that performs a mutual TLS (mTLS) handshake to derive endpoint information, allowing secure connections without dedicated proxy ports and decrypting all traffic, using Server Name Indication (SNI) and client certificates for user and customer identification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If explicit HTTP proxy is used to access destinations from remote locations, then user identification can be obtained through cookie decryption, but security concerns are introduced and dedicated non-standard ports are required which are filtered in guest Wi-Fi environments
Solution Approach 1:
The patent changes the identification mechanism from HTTP cookies to TLS client certificates. By using certificate-based authentication with mutual TLS (mTLS), the system obtains user identification without requiring HTTP proxy decryption, thereby eliminating security vulnerabilities while maintaining the ability to identify users and enforce policies
Solution Approach 2:
The patent introduces an HTTPS proxy as an intermediary that establishes mutual TLS connections with endpoints. This intermediary uses client certificates for authentication and Server Name Indication (SNI) for identification, allowing the proxy to obtain user information without decrypting application-layer traffic, thus resolving the contradiction between identification and security
2Adaptability or versatility
If explicit HTTP proxy is used with dedicated ports for multitenant services, then tenant traffic can be distinguished, but port availability is limited and non-standard ports are filtered in guest Wi-Fi environments
Solution Approach 1:
The patent makes the proxy service universal by using standard HTTPS ports (443) instead of dedicated non-standard ports. The mutual TLS handshake with client certificates and SNI enables the proxy to distinguish tenant traffic on common ports, making the service accessible in guest Wi-Fi environments and other restricted networks while maintaining multitenancy capabilities
3Loss of information
If HTTP proxy decrypts TLS traffic to obtain user identification, then cookies can be deciphered for customer and user identity, but all traffic decryption is required which introduces security risks and performance overhead
Solution Approach 1:
The patent performs user identification at the TLS handshake stage before application-layer traffic is exchanged. By extracting client certificate and SNI information during the initial mTLS connection establishment, the proxy obtains user identity without needing to decrypt subsequent application traffic, thereby reducing complexity and security risks while maintaining identification capability
Data Source
AI summary
Systems and methods for a Hypertext Transfer Protocol Secure (HTTPS) proxy service include monitoring traffic via a cloud, the traffic being monitored inline between one or more endpoints and one or more destinations; performing a mutual TLS (mTLS) handshake with an endpoint of the one or more endpoints based on a request to a destination of the one or more destinations; deriving endpoint information based on the mTLS handshake; and performing one or more actions on the request based on the endpoint information.