Kernun UTM supports network communication securing using the standard SSL (Secure Sockets Layer) protocol and its newer version TLS (Transport Layer Security). As the SSL/TLS protocol ensures end-to-end security, Kernun UTM cannot read or modify data from an SSL/TLS connection between a client and a server. This means that protocols using SSL/TLS encapsulation, e.g., HTTPS, POP3S, or IMAP4S, cannot be processed by a protocol-specific proxy. Instead, generic TCP proxy is usually used to forward such communication. In the case of HTTPS, a nontransparent HTTP proxy can be utilized for tunneling HTTPS data in an HTTP connection with the CONNECT HTTP request method. Sometimes, however, we need to have access to encrypted data for the purposes of analysis or even modification. An example is antivirus checking of files transferred via HTTPS.

The configuration described in this section is useful for fixed secure tunnels, e.g., via tcp-proxy, or for securing a single HTTP server by http-proxy. It is unsuitable for inspecting HTTPS traffic between ordinary HTTP clients (browsers) and servers, because the proxy presents a single server certificate (containing a single fixed host name) for any server accessed by a client. Common behavior of browsers is to compare the accessed server host name with the name in the server certificate and to issue a security warning if they do not match. If you need to handle this, HTTPS inspection, introduced in Section 19, “HTTPS Inspection”, is a viable option.

To access data protected by SSL/TLS, a proxy must split the communication into two SSL/TLS connections. Data from a client is first sent to the proxy via the first secure connection terminated on Kernun UTM. The encrypted data stream is decrypted by the proxy, processed, encrypted again and sent to the server via the second secure connection. Data from the server is passed via the two connections in the opposite direction. It is also possible to convert the unencrypted version of an application protocol (for example, HTTP) used by a client to the encrypted version (for example, HTTPS) accepted by a server, or vice versa.

An example of a proxy that uses SSL/TLS security is presented in Section 14.7, “HTTP Authentication Proxy”, and its configuration is shown in Figure 5.51, “Configuration of the HTTP authentication proxy”. This proxy converts a secured connection from a client to plain HTTP sent to the server. Another example is depicted in Figure 5.39, “SSL/TLS security configuration”. It is an HTTP proxy that enforces authentication of the remote server and also authenticates Kernun UTM to the remote server.

Figure 5.39. SSL/TLS security configuration

The parameters of an SSL/TLS connection are defined by the section ssl-params . All the available parameters are explained in ssl(5). In our example, this section selects the X.509 certificate with the related private key used by the proxy to authenticate itself to clients and servers (item id), and the list of certification authority certificates (auth-cert) with the related certificate revocation lists (crl) for verification of certificates provided by peer clients and servers. The verify-peer item forces the proxy to request and verify certificates of peers. If a peer does not provide a certificate or the certificate cannot be verified, the SSL/TLS handshake fails and the session is terminated.

The client-ssl SSL item in the session-acl INTOK section switches the connection from the client to the SSL/TLS mode and sets the protocol parameters. If the client establishes an encrypted connection and sends a valid certificate, it can send an HTTP request. Otherwise, the session is terminated. After receiving an HTTP request, the proxy searches for a request ACL. It selects request-acl TNS-CERT only if the client's certificate contains “SSL access” in the subject field, because of the client-cert-match item. The request ACL enables SSL/TLS on the connection to the server and sets the protocol parameters. The server-cert-match item defines conditions that must be fulfilled by the server's certificate (it must contain a common name ending by “kernun.com” in our example). Note that if the client-cert-match item is not matched, the single ACL is skipped and the search continues at the next request ACL, whereas if the server-cert-match item is not matched, the request is terminated immediately.

If you apply this kind of configuration and access a Web server via the proxy, your Web browser will show that the peer certificate is that of the proxy. In the proxy log, you will see details of the client's and server's certificates as received by the proxy.