SSH Tectia Client and SSH Tectia ConnectSecure can be used for transparent tunneling of TCP connections. Both SSH Tectia products can capture all network communication originating from client-server applications on the local workstation such as email clients, web browsers, and other software; and tunnel the connections to any Secure Shell server.
Transparent TCP tunneling feature can be used, for example, to enable company employees access their e-mail, the company intranet pages and shared files securely even when working outside the office.
SSH Tectia Client and ConnectSecure enable transparent TCP tunneling without the need to modify the tunneled applications. Hence, the main barrier for wider adoption of Secure Shell tunneling is eliminated, as there is no more need to reconfigure the local host addresses in the application client's network settings.
SSH Tectia Client and SSH Tectia ConnectSecure can secure network client applications that initiate connections to server applications using TCP communications. Other network protocols such as UDP are not supported. Note that applications that initiate connections from the server to the client are not supported.
- Broad application support
Transparent TCP tunneling can be used to encrypt any TCP-based user client/server application including both commercial application software and internal legacy applications.
- Authentication by applications
The client-server applications carry out their own authentication procedures, if any, the same way they would without the encrypted tunnel.
- No application modifications needed
Transparent TCP tunneling requires no re-configuring of the application software or port settings. The Connection Broker configuration contains all necessary settings.
- Easy configuration
The applications to be tunneled and the other tunneling settings are defined in the Connection Broker configuration with filter rules. The configuration can be made so that the SSH Tectia product uses the user name and the destination host definition from the tunneled application, so that it is not necessary to create a separate rule for each destination server. Both SSH Tectia Client and ConnectSecure can use the same configuration format.
- Fine-grained policy control
Administrators can freely define application security policies including rules to tunnel, allow plaintext, or block specific client-side application connections. The flexible configuration interface provides administrators with multiple ways of specifying the tunneled applications; applications can be identified according to destination address and/or port, application name, or location of the application client binary.
The principle of transparent TCP tunneling is shown in Figure 3.4.
The following steps happen in transparent TCP tunneling:
A user or script on the local host starts an Application client that begins to establish a connection to the Application server.
The SSH Tectia connection capture module captures the connection before it leaves the client side. Only user processes are captured, and processes running with the
SYSTEMaccount are passed through.
The SSH Tectia connection capture queries from the Connection Broker the filter rules that specify which connections to capture, and what filter rules to apply to the connection; whether to block it, let it pass directly, or to tunnel it securely through a Secure Shell server.
The filter rules are defined in the Connection Broker configuration. Connections can be captured based on the application used and the destination address and/or port, or all application connections can be captured.
If the connection requires tunneling, the Connection Broker creates a TCP listener as a local tunnel end point and the application connection is redirected to that local end point.
SSH Tectia Client or ConnectSecure can extract the user name, password, and destination host name from the secured application, and use them for authentication and connection setup with the Secure Shell server.
The Connection Broker module creates an authenticated and encrypted Secure Shell tunnel to a Secure Shell server, which, if necessary, relays the traffic to the destination host. The Secure Shell server can be the application server specified in the original connection request, or another server configured in the filter rules.
The secure tunnel is terminated at the Secure Shell server.
The Application server is the end point of the connections. If the Application server is located on a third host, the relayed connection from the Secure Shell server to the application server will be unsecured. This is why it is recommended that there is at least one Secure Shell server in each physically secured area, for instance in a machine room.