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 Application-level Gateway (for example, the certificates are valid, and only the allowed encryption algorithms are used), Application-level Gateway 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, Application-level Gateway 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, Application-level Gateway checks if encryption is required on the given side. It is not necessary for SSL to be enabled on both sides - Application-level Gateway 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 Application-level Gateway behaves as an SSL server) and the server (when Application-level Gateway behaves as an SSL client):

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

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

  • 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, Application-level Gateway verifies the server's certificate first, and then sends its own certificate for verification.

Previous Up Next
 Home