Applies to: KNA, KMA, KOA, KWA

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

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. 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.5, “HTTP Authentication Proxy”, and its configuration is shown in Figure 6.46, “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 6.38, “Cooperation of HTTP and FTP”. It is an HTTP proxy that enforces authentication of the remote server and also authenticates Kernun to the remote server.

Figure 6.38. Cooperation of HTTP and FTP

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