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

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

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

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:

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

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

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”.

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:

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

Figure 5.82. HTTPS termination proxy configuration