Developers Are Finding SOCKS5 to Be a Good Fit
SOCKS is nothing new. It was developed in 1990, and SOCKS5 has been around since 1995. But it wasn’t until this year that SOCKS has begun to gain widespread support among companies who are now adding it to their firewalls, virtual private networks (VPN) and other products.
SOCKS5 is an IETF standard that is gaining broad acceptance among providers of Internet-based client/server solutions -- such as applications, proxy/cache servers, firewalls and VPN products -- as the means for Internet-based applications to securely traverse enterprise network firewalls.
NEC Systems Laboratory Inc. (Melville, N.Y., www.nec.com) played the largest role in updating the old standard so that the company could use SOCKS in its EZClient software, which enables Internet application vendors and client operating system providers with a way to embed client-side support for SOCKS5 in applications and operating systems
With SOCKS, clients make a request to communicate with the application server. SOCKS creates a secure proxy data channel -- a reliable, impenetrable link to the server -- and then transmits data between the client and the server. From the client’s perspective, SOCKS is transparent. From the server’s perspective, SOCKS is a client.
This process creates new options for software developers. First, by embedding SOCKS support into existing software, developers enable data to be used in a Web environment. Also, the application server’s firewall does not need support for the application. The session-level proxy will open up the firewall and enable the data to traverse anyway, without the firewall’s being compromised.
SOCKS is interoperable with IPSec, the IETF standard for secure IP packet communication. Since IPSec is located at the network layer, delivering peer-to-peer protocol, and SOCKS is located at the session layer, delivering client/server protocol, they can easily coexist within most corporate networks.
The problems with earlier versions of SOCKS related to the difficulty of client-side configuration. SOCKS5 makes configuring clients easier and includes support for UDP and TCP applications such as SNMP and audio/video applications such as RealAudio. It supports communications among networks with different IP addressing schemes, and supports authentication and encryption.
In a SOCKS network, all network application data flows through SOCKS, enabling SOCKS to collect, audit, screen, filter and control the network data, and create a network application data warehouse. During the setup of proxy circuits, SOCKS can also authenticate, negotiate the message security level, and authorize.
SOCKS4 performed three functions: connection request, proxy server setup and application data relay. SOCKS5 brings authentication to the table. With authentication, SOCKS5 adds two messages. The application client sends the first message to SOCKS, declaring the authentication methods that the client can support. SOCKS sends a message back to the client, announcing the method the client should use. SOCKS determines the authentication method on the basis of the security policy defined in the SOCKS server configuration. If the client-declared methods fail to meet the security requirement, SOCKS drops communication.
Marc VanHeyningen, Internet security manager for Aventail Corp. (Seattle, www.aventail.com), a VPN manufacturer that specializes in the extranet, says the new authentication features of SOCKS5 is what drew his company to the technology. "We wanted to go in and transparently add [authentication] support to Winsock applications, and SOCKS5 lets us do that," says VanHeyningen.
Aventail has teamed with the IETF, Intel Corp., Microsoft Corp., NEC and Novell Inc. to draft the next version of SOCKS. In addition to supporting multicast and a variety of other new enhancements, a key area of collaboration in version 6 will be to further define interoperability between SOCKS and IPSec. That issue and others will be discussed at next week’s SOCKS Summit 1998 in Santa Clara, Calif. The conference will be sponsored by NEC and Stardust Forums (Campbell, Calif., www.stardust.com).