Firewall SNI Extraction for Secure Protocol Filtering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Firewalls struggle to detect and filter secure protocols like SSL/TLS, as they encrypt data communications, making it difficult to extract destination domain information necessary for policy-based filtering, especially since a single IP address can host multiple virtual domains without clear indication of the intended domain.
Innovation Solution
Utilizing the Server Name Indication (SNI) extension in the TLS protocol to extract the destination domain from the client hello message, allowing firewalls to intercept and parse this unencrypted information for policy application without decrypting the entire communication, thereby enabling early filtering and reducing state tracking.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If firewalls decrypt entire SSL/TLS sessions to inspect content, then policy-based filtering capability is improved, but processing overhead and performance degradation worsen
Solution Approach 1:
The patent extracts only the necessary destination domain information from the SNI extension in TLS handshake messages, rather than decrypting the entire encrypted session. This selective extraction allows firewalls to obtain sufficient information for policy-based filtering while avoiding the heavy computational burden of full decryption, thus resolving the contradiction between filtering capability and processing performance
Solution Approach 2:
The patent performs destination domain extraction during the TLS handshake phase, before the encrypted session is fully established. By obtaining the destination domain information early in the connection setup, the firewall can apply policy filtering decisions upfront without needing to maintain state throughout the entire encrypted session, improving both filtering effectiveness and performance
2Reliability
If firewalls track encrypted session state to apply policies, then security control is improved, but complexity of state management worsens
Solution Approach 1:
The patent extracts the destination domain from the SNI extension during the TLS handshake, obtaining sufficient information for policy enforcement without needing to track the entire encrypted session state. This extraction approach maintains security control by capturing the essential routing and filtering information while dramatically reducing the complexity of state management throughout the encrypted communication
Solution Approach 2:
The patent applies partial action by extracting only the specific destination domain information needed for policy enforcement from the TLS handshake, rather than attempting to fully decode or track all aspects of the encrypted session. This partial extraction provides sufficient security control while avoiding the excessive complexity of comprehensive session state tracking
3Measurement precision
If firewalls wait for decryption to extract destination domain, then accuracy of domain identification is improved, but timing of policy application worsens
Solution Approach 1:
The patent performs destination domain extraction during the TLS handshake phase, utilizing the SNI extension which contains the destination domain information in plaintext before the encrypted session begins. This preliminary extraction enables the firewall to apply policy filtering decisions immediately without waiting for session decryption, achieving both accurate domain identification and timely policy enforcement
Solution Approach 2:
The patent uses the SNI extension as an intermediary that carries the destination domain information in plaintext during the TLS handshake. This intermediary mechanism allows the firewall to obtain accurate domain identification without needing to decrypt the subsequent encrypted session, effectively bridging the gap between domain accuracy requirements and timing constraints
Data Source
AI summary
Techniques for destination domain extraction for secure protocols are disclosed. In some embodiments, destination domain extraction for secure protocols includes monitoring network communications between a client and a remote server; determining if the client sends a request to create a secure connection with the remote server (e.g., in which the network communications are initiating a setup for a secure protocol-based connection); and extracting a destination domain from the request to create the secure connection with the remote server. In some embodiments, the secure protocol is a secure sockets layer (SSL) protocol or transport layer security (TLS) protocol, and the destination domain is extracted from the server name indication (SNI) of a client hello message sent from the client to the remote server. In some embodiments, destination domain extraction for secure protocols further includes applying a policy (e.g., a security policy) based on the destination domain to filter traffic using a security device.