3.2.1. Behavior of the SSL framework

The SSL framework inspects SSL/TLS connections, and also any other connections embedded into the encrypted SSL/TLS channel. SSL/TLS connections initiated from the client are terminated on the firewall, and two separate SSL/TLS connections are built: one between the client and the firewall, and one between the firewall and the server. If both connections match the configuration settings of Zorp (for example, the certificates are valid, and only the allowed encryption algorithms are used), Zorp inspects the protocol embedded into the secure channel as well. Note that the configuration settings can be different for the two connections, for example, it is possible to permit different protocol versions and encryption settings.

When a firewall rule matches an incoming connection, Zorp starts the Service specified in the firewall rule to inspect the connection. The Encryption policy set in the Service determines the encryption settings used in the connection.

  • For the details of the attributes related to the SSL framework, see Section 5.5, Module Encryption.

  • Several configuration examples and considerations are discussed in the Technical White Paper and Tutorial Proxying secure channels - the Secure Socket Layer, available at the Balasys Documentation Page.

Depending on the scenario (TwoSidedEncryption, ClientOnlyEncryption, and so on) set in the Encryption policy, the SSL framework selects the first peer to perform the SSL handshake with.

As part of the handshake process, Zorp checks if encryption is required on the given side. It is not necessary for SSL to be enabled on both sides - Zorp can handle one-sided SSL connections as well (for example, the firewall communicates in an unencrypted channel with the client, but in a secure channel with the server). If SSL is not enabled, the handshake is skipped for that side.

When SSL is needed, the Service collects the required parameters (keys, certificates, and so on) from the Encryption policy.

The SSL handshake is slightly different for the client (in this case Zorp behaves as an SSL server) and the server (when Zorp behaves as an SSL client):

  • Client-side (SSL server) behavior. In the client-side connection Zorp acts as an SSL server, and shows the client a certificate.

    If peer authentication is enabled (that is, the required and trust_level attributes of the verifier used in the Encryption policy is properly set), Zorp sends a list of trusted CAs to the client. If the client returns a certificate, Zorp verifies it against the trusted CA list and their associated revocation lists, and also checks the validity of the certificate.

  • Server-side (SSL client) behavior. The server-side handshake is similar to the client-side handshake only the order of certificate verification is different. On the server side, Zorp verifies the server's certificate first, and then sends its own certificate for verification.

Previous Up Next
 Home