Processing CONNECT requests

During processing of HTTPS traffic, the result of application of the Block and Redirect actions differs from the result of application of these actions to HTTP traffic. The user will not see a block page and will not be redirected to the specified URL. Instead, the connection is terminated.

The reason for this is that in order to establish encrypted HTTPS connections the user's computer requests from the proxy server a connection to the web server using an HTTP message containing the CONNECT method (hereinafter also "a CONNECT request"). The ability of proxy servers to process CONNECT requests and reply to them is limited at the level of the HTTP protocol. The proxy server can either notify the user about a successful connection, or terminate the connection.

In order for the Block and Redirect to be applied correctly, you need to enable decryption of TLS/SSL connections and add the CONNECT method to exclusions or create a bypass rule for it. If there are no traffic processing rules that allow CONNECT requests, the connection will be terminated.

Allowing CONNECT requests may lead to reduced security of the corporate IT infrastructure. It is recommended to add the CONNECT method to exclusions only in those traffic processing rules for which the display of the block page or redirects are critical.

This article further covers the specifics and differences between the processing of HTTP traffic transmitted using standard HTTP messages and HTTPS traffic when CONNECT requests are used to establish encrypted connections.

Processing of standard HTTP messages

Most HTTP methods (for example, GET, POST, DELETE, HEAD, OPTIONS, PATCH, PUT, and TRACE) are intended for exchanging HTTP messages between the client (user computer) and the web server on which the requested web resource is stored. Kaspersky Web Traffic Security can scan such HTTP messages and can apply all available actions to those messages. The principles of HTTP message processing in Kaspersky Web Traffic Security are illustrated in the figure below.

Principles of HTTP message processing

Numbers in the figure correspond to the following stages of processing of standard HTTP messages:

1. A user requests access to a web resource. This request is relayed to the proxy server.
2. The application checks whether the requested web resource meets the criteria of access rules.
3. If the application of an access rule results in the Block action, the user sees the block page. If the Redirect action is applied, the user is redirected to the specified URL.
4. If the application of an access rule results in the Allow action, the application proceeds to scan traffic using protection rules or the default protection policy. If no threats are detected, the user request is redirected to the web server.
5. The response received from the web server is also scanned by protection modules for any viruses or other threats. When threats are detected, the application blocks traffic. If no threats are detected, the application relays the response from the web server to the user's computer.
6. During an unauthorized access attempt, intruders can intercept data because traffic is transmitted in unencrypted form.

Specifics of processing of CONNECT requests

When an attempt is made to access a web resource via the HTTPS protocol, the user's computer sends a CONNECT request to the proxy server, requesting a connection to the web server. As a result of the exchange of encryption settings and security certificates, a tunneled secure connection over the TLS protocol is established between the user's computer and the web server. Within this tunnel, the client and the web server exchange HTTP messages using standard HTTP methods (GET, POST, etc.). By default, the proxy server cannot analyze the contents of the encrypted connection or interfere with the exchange of messages within the tunnel. The mechanism of processing of default encrypted connections is illustrated in the figure below.

Mechanism of processing of default encrypted connections

Numbers in the figure correspond to the following stages of processing of default encrypted connections:

1. The user's computer sends a CONNECT request to the proxy server, requesting an encrypted data channel with the web server.
2. The application checks whether the requested web resource meets the criteria of access rules.
3. If the application of rules results in the Block or Redirect action, the connection is terminated. The user will not see the block page and will not be redirected to the specified URL.
4. If the application of access rules results in the Allow action, the application sends a CONNECT request for further processing by protection modules.
5. After a successful scan of the CONNECT request by the protection modules, the proxy server establishes an encrypted data channel between the user's computer and the web server.
6. The user's computer exchanges standard HTTP messages with the web server inside the encrypted data channel. The proxy server cannot access such messages and have them scanned by the protection modules because the data being transmitted is encrypted.
7. The response from the web server is also relayed to the user's computer directly without being canned by the protection modules. This reduces the level of protection of the corporate IT infrastructure, since the user's computer can receive traffic containing threats.
8. During an unauthorized access attempt, intruders cannot intercept data because traffic is transmitted inside an encrypted channel.

To enable the application to scan traffic transmitted inside an encrypted data channel using the protection modules, you need to configure decryption of TLS/SSL connections. The mechanism of processing of encrypted connections with enabled decryption of TLS/SSL connections is illustrated in the figure below.

Mechanism of processing of encrypted connections with enabled decryption of TLS/SSL connections

Numbers in the figure correspond to the following stages of processing of encrypted connections with enabled decryption of TLS/SSL connections:

1. The user's computer sends a CONNECT request to the proxy server, requesting an encrypted data channel with the web server.
2. The application checks whether the requested web resource meets the criteria of access rules.
3. If the application of an access rule results in the Block or Redirect action, the connection is terminated. The user will not see the block page and will not be redirected to the specified URL.
4. If the application of access rules results in the Allow action, the application sends a CONNECT request for further processing by protection modules.
5. After a successful scan of the CONNECT request by the protection modules, encrypted data channels are established between the user's computer and the proxy server and between the proxy server and the web server.
6. The user's computer exchanges standard HTTP requests with the web server inside the encrypted data channel. The application is granted access to all data being transmitted and can apply protection rules to them.
7. The application checks whether the requested web resource meets the criteria of access rules.
8. If the application of an access rule results in the Block action, the user sees the block page. If the Redirect action is applied, the user is redirected to the specified URL.
9. If the application of an access rule results in the Allow action, the application proceeds to scan traffic using protection rules or the default protection policy. If no threats are detected, the user request is redirected to the web server.
10. The response received from the web server is also scanned by protection modules for any viruses or other threats. When threats are detected, the application blocks traffic. If no threats are detected, the application relays the response from the web server to the user's computer via an encrypted data channel.
11. During an unauthorized access attempt, intruders cannot intercept data because traffic is transmitted inside an encrypted data channel.