Secure Interoffice Communications

This is originally from the paper:

Secure Inter-office communications across the Internet using WinGate 2.0a

This document is still applicable to the current version of WinGate.

Introduction

Many companies are faced with the problem each year of how best to provide communications for their core business functions. These functions are typically based around systems such as order-entry systems, file-server access, remote control, and ancillary communications systems such as email or groupware. A fundamental requirement for many of these systems is security; file servers and email often contain sensitive or proprietary information..

Traditionally, for a company with remote offices, Wide-Area Networks have provided the communications backbone to support these services. These solutions are often very expensive. Leased lines cost a lot of money to rent particularly over long distances. This communications backbone is often under-utilised. In many circumstances, expensive systems have had to be developed to circumvent the use of communications, as the costs have been prohibitive.

Now there is another way. Using the general purpose encryption and security built into WinGate 2, a company can set up secure links between its offices using the Internet as a backbone. This has the opportunity to revolutionise the way companies do business, drastically reducing costs and increasing the options for communications. Using Internet and Intranet technologies (which are becoming more and more prevalent in the corporate environment), WinGate can provide secure file access, secure email, secure telnet-based order-entry systems, secure database access and much more.

How It Works

With the release of WinGate 2 on 28 February 1997, a fundamental change was made. Support was included for encrypted firewall-firewall communications at a building-block level. Specifically the Mapping Proxies were given the capability to use encryption.

This provides a communications pipe where the data is encrypted in mid-stream.

There are a couple of principles that are useful to explain further here.

Client-server applications.

A client-server application consists of a situation where one process communicates with another to perform a task. The task is usually requested by the client process, performed by the server process, and results are sent back to the client process. The communication is often achieved over a connection-oriented network service such as a named pipe, a TCP connection (i.e. TCP/IP), a NetBIOS session or other. Typical examples of this are telnet servers with terminal clients, SQL Server and SQL workstation, FTP servers and clients, NFS clients and servers etc.

TCP Connection

A TCP connection provides two-way, reliable, sequenced data transfer using the TCP (Transfer Control Protocol) normally over the network protocol IP (Internet Protocol). Hence the name TCP/IP. This allows communications across networks between a process on one machine, and another process on another machine.

TCP Port

A TCP port is a means of identifying a process within a machine that a TCP connection belongs to. Every time a TCP connection is made, it is kept track of by the combination of IP address and port number of each end of the connection. Normally server processes “listen” on a well known pre-determined port number (i.e port 80 for Web servers, 21 for FTP servers etc), so that a client can request a connection to them. The client process however is allocated a unique port number by the operating system for its end of the connection, and this guarantees the uniqueness of the connection information used by TCP to provide the TCP connection. In this way, the same machine can make many unique TCP connections to the same process on another machine, as each connection is unique by virtue of the client port number.

Mapping Proxy

Mapping proxies can be thought of as a means to extend or project an interface from one machine to another across a network, thereby making the projected machine appear to be somewhere else (like on your local LAN). In WinGate, a mapping proxy uses TCP connections to project the interface. How it works is this: a process (usually a client process) connects to WinGate on a predetermined TCP port number (configured in WinGate). WinGate then immediately connects to a predetermined location (also specified in WinGate), and any data that is sent from either client or server to each other, is relayed by WinGate. In short the client thinks it is talking to the server, and the server thinks it is talking to the client. WinGate itself takes no interest in the content of the data relayed between the client and the server.

Encrypted Mapping Proxy

The encryption support introduced with WinGate 2.0 allowed for one mapping proxy to connect to another, authenticate, and allow for the data relayed to be encrypted. Since a mapping proxy is like a client and a server (as are all proxies), you can specify whether the client communications or the server communications or both will be encrypted. To set up the secure link you specify on the client side (the proxy that a client will connect to) that incoming communications will not be encrypted (as the client does not know the encryption protocol). Communications out will be encrypted, as the mapping proxy will be connecting to another mapping proxy that will be expecting incoming communications to be encrypted.

The encryption scheme is based on a 128 bit key with a challenge response mechanism, so that at no time is any information sent that could be used to determine the encryption keys. This requires that a username and password are known at each end of the link (i.e in each copy of WinGate) before the communications will take place.

WinGate 2 Services

The building-block setup of WinGate 2 allows for a high degree of flexibility, and numerous options for setting things up. A user can create any number of new services and specify all sorts of access controls and parameters for each one.

The other proxy services built into WinGate also have built in support for cascading, or obtaining connections through other services. What this means is that for example, the HTTP proxy can obtain access to servers using the SOCKS4 protocol through a SOCKS server, as can the telnet gateway, and the FTP proxy. This effectively provides a means for protocol conversion to traverse different networking obstacles (e.g other firewalls etc).

Examples

the following examples provide a more practical look at some of the typical scenarios, and how things may be set up to implement them. The following three scenarios are considered:

1. Secure access to file server files

2. Secure access to telnet-based order-entry systems

3. Secure access to corporate web servers

Secure access to file server files

By using the FTP proxy in WinGate it is possible to gain secure access to a remote FTP server. One way it could be put together is this.

Remote Office LAN WinGate installation

The FTP proxy is configured to connect out via a SOCKS server on interface localhost port 2080. However, on port 2080 instead of actually running a SOCKS server, you run a mapping proxy which makes an encrypted connection to a port (say 2080) on your main office WinGate server.

Main Office LAN WinGate installation

The encrypted mapping proxy on port 2080 maps through to localhost on say port 3080, on which port you are running a SOCKS server bound to the localhost interface. That’s it.

Now any FTP client on the remote office network can access any FTP server on your main office network.

What is effectively happening, is that using the encrypted mapping proxy, the SOCKS server on the main office network is projected into the remote office network, and the FTP proxy is using this to gain access to FTP servers on your main office network.

One note here, is that in order for this to work, the FTP clients must be configured for PASV mode transfers.

Other options, depending on preference, could be to run the Remote Office FTP proxy on a different port (you can even create another one specifically for this), and have it specify a non-proxy-request remote server. Then when your clients want to connect to the server, they do not need to use a proxy-setup FTP client, they can treat their local (Remote Office WinGate) FTP proxy as the Main Office FTP server.

Secure access to telnet-based order entry systems

Many corporate order entry systems run on Unix machines, and use telnet (or terminal) applications for users to log in and work on the system

Remote Office LAN WinGate installation

You run an encrypting Mapping proxy on say port 2023 with the remote host being your main office WinGate machine on say port 2023.

Main Office LAN WinGate installation

The encrypted mapping proxy on port 2023 maps through to your Unix machine on port 23. That’s it. You may also configure your mapping proxy to only accept connections from known locations at certain times etc.

Now for your clients to work on the server, they simply connect to port 2023 on their local WinGate machine, which connects them through to the mapping proxy on the main office WinGate machine, which decrypts the data, and plugs them through to the Unix machine telnet server.

Secure access to corporate web servers

Many corporate networks now run Web servers (HTTP servers) to disseminate corporate information to their employees or clients.

Remote Office LAN WinGate installation

You run an encrypting Mapping proxy on say port 2080 with the remote host being your main office WinGate machine on say port 2080.

Main Office LAN WinGate installation

The encrypted mapping proxy on port 2080 maps through to your web server machine on port 80. That’s it. You may also configure your mapping proxy to only accept connections from known locations at certain times etc.

Now for your browser to access the corporate web server, they simply type in the URL

http://wingate:2080/

Where wingate is the name of their Remote Office WinGate machine, and they have configured their browser not to use proxy for host “wingate”.

Summary

In short, it is possible to access corporate servers for a number of protocols. Protocols that do not explicitly support WinGate can be supported through the SOCKS protocol (e.g by installing an AutoSOCKS client on the remote office workstations. Client applications can use an encrypted projection of the SOCKS server on the main office LAN to carry out their client-server communications).

This means that any client server communications that uses exclusively TCP connections for communications can be configured to be accessed securely using the Internet as a backbone. Thereby offering not only the saving of leased line rentals, but also safe Internet access as well.

With the removal of the security issue, there is now no longer any major reason why companies need to avoid using the readily available and cheap bandwidth that is available on the Internet.