19. HTTPS Inspection

Kernun UTM, namely the http-proxy, provides means for inspection of the HTTPS traffic. HTTPS inspection is available for both transparent and non-transparent connection mode.

An example of the http-proxy configured for HTTPS inspection is available in the /usr/local/kernun/conf/samples/cml/https-insp.cml file. The example demonstrates the following scenario:

The configuration described in this section is intended for providing access to an a priori unknown set of HTTPS servers. For example, access of clients in the internal network to HTTPS servers in the Internet. If you need a secure tunnel between two points or HTTPS to a single server, the SSL/TLS configuration from Section 13, “Secure Communication Using SSL/TLS” may be more appropriate.

19.1. Certificates

HTTPS uses certificates as a means to verify the server identity. HTTPS inspection (by its nature) breaks into the connection between the client and the server, which would be detected by the client and reported as an Untrusted connection warning to the user. To prevent this issue, the proxy generates a new certificate which mimics the original certificate. It is issued by the certification authority (CA) controlled by the Kernun UTM. By importing this CA to the list of trusted CAs of the client browser the above mentioned Untrusted connection warning is prevented.

There are two CAs needed for proper work of the HTTPS inspection: GOOD and BAD. The HTTP proxy selects one of them for signing the certificate that is presented to the client as the server certificate.

The GOOD CA is used for servers, whose certificates were successfully verified by the proxy. The clients are expected to import the GOOD certificate as the trusted certification authority. The BAD CA is used for servers, whose certificates cannot be verified by the proxy. The clients MUST NOT import the BAD certificate.

As the result, the web pages, whose server certificate was succsessfully verified by the proxy are presented with certificates signed by the GOOD CA to the client. The client accepts them without complains, because the client trusts the GOOD CA.

By contrast: web pages, whose server certificate cannot be verified by the proxy, trigger the Untrusted connection alarm, since they are presented to the client with the certificate signed by the BAD CA, which the client does not trust.

The configuration is shown in figure Figure 5.78, “Certification authorities for HTTPS inspection”. The GOOD CA and the BAD CA are provided to the proxy in the section fake-cert as item fake-cert.auth-ca (the GOOD CA), and item fake-cert.fail-ca (the BAD CA). Besides the two CA, there is also a private key needed for signing the faked certificates. The key is specified in section fake-cert.key.

The proxy uses the list of the trusted CAs for verifying the server certificates. The list is presented in the section SSL-INSP-SERVER-SSL. The default list of the trusted CA is provided by Kernun in /usr/local/kernun/conf/samples/cert/dist_auth_cert.pem. This list is the root certificate bundle with certificates merged from Internet Explorer and the Mozilla Project. Main Czech and Slovak certification authorities are included as well. If you need to modify the list, copy the file to another location and change the path for the shared-file SSL-INSP-AUTH appropriately. The file contains concatenation of certificates in the PEM format, so you can delete existing certificates or append new ones using any text editor.

Figure 5.78. Certification authorities for HTTPS inspection

Certification authorities for HTTPS inspection

Note

The CA can be created by command mkcert.sh, for example:

mkdir /usr/local/kernun/conf/ssl-insp-certs
cd /usr/local/kernun/conf/ssl-insp-certs
mkcert.sh -g . -c "Kernun SSL Inspection" -F good.crt -K good.key
mkcert.sh -g . -c "Server verification failed!" -F bad.crt -K bad.key

The private key needed can be created by command openssl, for example:

cd /usr/local/kernun/conf/ssl-insp-certs
openssl genrsa -out private-key.pem 2048 -nodes

19.2. HTTPS inspection ACL flow

When both transparent and non-transparent HTTPS is used in a single http-proxy, several session-acls and request-acls are used to internally transform the non-transparent traffic to transparent as well as to transform the HTTPS to HTTP by inspecting the SSL, or to apply access control without inspecting the SSL. After the transformations, a single set of request-acls is used to implement the security policy.

HTTPS traffic can be:

  • Accepted without HTTPS inspection. The proxy establishes TCP tunnel between client and server, ending the ACL processing at request-acl level.

  • Blocked without HTTPS inspection. In transparent mode, TCP connection to the client is reset before connecting to the server. In non-transparent mode, an error message is sent to the client.

  • Accepted in HTTPS inspection. The proxy decrypts the SSL/TLS, processes the HTTP communication and re-encrypts it afterwards. The decrypted HTTP communication is processed the same way as (both transparent and non-transparent) HTTP. When different behaviour is desired, session-acl item connect-session-acl can be used to detect the session-acl that accepted the HTTPS connection.

  • Denied in HTTPS inspection. Proxy decrypts and re-encrypts the HTTP communication. Proxy can either send the client properly encrypted error document or send the requested server response signed by BAD CA as described by Section 19.1, “Certificates”.

Figure 5.79, “HTTPS inspection ACL flow” provides the schema of ACL flow during the processing of HTTP and HTTPS traffic in both transparent and non-transparent mode.

Figure 5.79. HTTPS inspection ACL flow

HTTPS inspection ACL flow

19.3. Transparent mode

The http-proxy by default expects the client to send an HTTP request, it can be told to expect TLS by specifying either sni-insp or client-ssl in the session-acl.

In transparent HTTPS, server hostname is specified in HTTP protocol which is encrypted. However, it is usually also specified in SNI in the first TLS message which is not encrypted yet. See Section 19.5, “SNI inspection in HTTPS” for more details. In order to obtain the server hostname from TLS layer before HTTPS inspection, item sni-insp is used. If an exception from HTTPS inspection takes effect, the proxy establishes TCP tunnel to the server.

If the traffic is to be HTTPS inspected, item capture-connect is used to make the proxy virtually close the current session and reexute it. Afterwards, HTTPS inspection is turned on by referencing the client-ssl section which defines item fake-cert. Subsequent request-acl processes the request as if it was plain HTTP.

The configuration of both transparent and non-transparent modes is shown in Figure 5.80, “HTTPS inspection configuration”. The session-acl S-HTTPS-TRANSP uses the item sni-insp to obtain server name as well as to validate the first SSL/TLS message. Exceptions from SSL inspection are defined in request-acls R-HTTPS-NO-INSP-CLIENTS and R-HTTPS-NO-INSP-SERVERS. Item request-method with value CONNECT can be used here because of item sni-insp which simulates the CONNECT method. Item capture-connect in request-acl R-HTTPS-INSP makes the proxy virtually close the current session and reexute it, which results in session-acl S-HTTPS-INSP getting matched because of item captured-connect. The session-acl S-HTTPS-INSP uses the client-ssl SSL-INSP-CLIENT-SSL and server-ssl SSL-INSP-SERVER-SSL. See Section 19.1, “Certificates” for details on these ssl-params sections.

Figure 5.80. HTTPS inspection configuration

HTTPS inspection configuration

19.4. Non-transparent mode

In non-transparent mode, HTTPS is recognized by HTTP request method CONNECT. Server hostname is specified in the enveloping HTTP so SNI inspection is not needed. Special item capture-connect is used for handling CONNECT requests. Afterwards, it is handled by the means described above in Section 19.3, “Transparent mode”.

19.5. SNI inspection in HTTPS

This section describes Server Name Indication (SNI) inspection that can be used to obtain server name from TLS handshake for usage in request ACLs. It is intended to be used in transparent HTTPS, because in non-transparent HTTPS, server hostname is specified in the enveloping HTTP.

When a client connects to an HTTPS server, the first message (SSL/TLS ClientHello) usually contains server hostname (SNI) that the server uses for detecting service requested by the client, because multiple hostnames can be hosted on a single IP address. SNI was introduced in TLS 1.0 and is optional, it is missing for example when user accesses an HTTPS web server using IP address instead of a hostname.

When SNI inspection is configured in session ACL, the first message from client is parsed. When it does contain SNI, server hostname and URI is changed from an IP address to a hostname for usage in request ACL. Afterwards, as described at Section 19.2, “HTTPS inspection ACL flow”, HTTPS inspection can be performed, the connection can be accepted without HTTPS inspection or the connection can be denied.

The result of SNI inspection can be used in request ACL item sni-result which has values:

specified

The request was a TLS 1.0 or higher ClientHello that contained SNI. Server hostname and URI for the subsequent request ACL was changed from an IP address to the hostname from SNI.

unspecified

The request was a TLS 1.0 or higher ClientHello that did not contain SNI. Server hostname and URI remained unchanged for request ACL matching.

ssl3

The request was a SSLv3 ClientHello that did not contain SNI because it is not in the SSLv3. Server hostname and URI remained unchanged for request ACL matching.

skype

The request was traffic specific for Skype. Server hostname and URI remained unchanged for request ACL matching. The request was either an invalid empty TLS 1.0 handshake message or TLS 1.0 ClientHello in SSLv2 record layer. Skype uses these requests for registration to the Skype network and for authentication. For the communication itself, Skype uses standard HTTPS so both skype and specified must be permitted in order for Skype to work. Skype can handle HTTPS inspection as well.

unknown-protocol

The request was an unknown protocol or malformed request so the SNI was not inspected. Server hostname and URI remained unchanged for request ACL matching.

19.6. TLS termination

The http-proxy can be used to provide access to an internal web server for clients in the Internet. When HTTPS is used, the proxy responds to the client with a TLS server certificate immediately after receiving the first message from the client, the ClientHello. If the proxy provides access to multiple internal web servers, it is necessary to select the correct server certificate for sending. That can be achieved by inspecting the SNI received in the ClientHello.

An example of reverse HTTPS proxy configuration is shown in Figure 5.81, “HTTPS termination global configuration” and Figure 5.82, “HTTPS termination proxy configuration”. The full configuration is located in /usr/local/kernun/conf/samples/cml/https-termination.cml. It describes an http-proxy that provides access to two web servers, server A and server B, located in internal network for clients in Internet. The clients are forced to use HTTPS when communicating, the proxy uses HTTP with server A and HTTPS with server B.

The proxy listens on the external network interface for connections from clients in the Internet. When a client connects, session-acl HTTPS-REVERSE-SNI-INSP performs SNI inspection. After the SNI inspection, the following request-acls have its value available in item server. The proxy chooses a request-acl from CAPTURE-CONNECT-CRT-A or CAPTURE-CONNECT-CRT-B which both perform capture-connect.

During the capture-connect, the proxy virtually closes the session and reexecutes it, entering session-acl phase once again. One of session-acls HTTPS-REVERSE-OK-CRT-A and HTTPS-REVERSE-OK-CRT-B is selected based on the request-acl that performed the capture. The selected session-acl also responds to the client's ClientHello with the specified server certificate and finishes the TLS handshake.

Now the proxy has TLS layer terminated and it is processing plain HTTP. It selects either request-acl A-PERMIT or B-PERMIT based on the address specified in HTTP request line. The selected request-acl relays the HTTP request to one of the servers located in the internal network. The server can be either HTTP or HTTPS. In the example server A is HTTP while server B is HTTPS.

Figure 5.81. HTTPS termination global configuration

HTTPS termination global configuration

Figure 5.82. HTTPS termination proxy configuration

HTTPS termination proxy configuration