SOCKS
Group: Challenger
Member: Lichun Zhan
Agenda







Introduction
SOCKS v4
SOCKS v5
Summary
Conclusion
References
Questions
Introduction



SOCKS was originally developed by David
and Michelle Koblas.
It is modified and extended by Ying-Da
Lee -- SOCKS v4.
SOCKS v5 is defined in RFC 1928 by
IETF.
Introduction – What is SOCKS



SOCKS is a generic, proxy protocol for TCP/IP
based networking application.
It provides a flexible framework for developing
secure communications by easily integrating other
security technologies.
SOCKS consists of two parts: SOCKS server and
SOCKS client.
Introduction – SOCKS Server and Client



SOCKS server is a program that is run on a host
that can communicate directly with both the
Internet and the internal computers on the network.
SOCKS client is a specially modified Internet client
programs that contacts the SOCKS server instead of
sending requests directly to the Internet.
According to the OSI model, the SOCKS server is
implemented at the application layer.The SOCKS
client is implemented between the application and
transport layers.
Place In OSI Layer
Client
SOCKS
Server
Application
Application
Application
Transport
Transport
Transport
Physical
Physical
Physical
Introduction – How does it work?




The client connects to a SOCKS proxy server.
The proxy server connects to the application
server on behalf of the client.
The proxy server relays data between the
client and the application server.
For the application server, the proxy server is
the client.
Introduction – Connection Setup
SOCKS Connection Setup
TCP Connect and
SOCKS Request
User
SOCKS Reply
SOCKS
Proxy
Server
TCP Connect
(SYN)
Server
TCP Connect
ACK
Introduction – Data Relay
SOCKS Data Relay Phase
Packet
User
Packet
SOCKS
Proxy
Server
Packet
Server
Packet
SOCKS V4 – Three functions

CONNECT:makes connection requests.

BIND: sets up proxy circuits

Relays application data
V4 – CONNECT request & reply

Request(from client to SOCKS server):
+------+-----+-------+-------+-------+--------+--------+---------+....+--------+
| VN | CD | DSTPORT |
# of bytes:


DSTIP
|
USERID
|NULL|
+------+-----+-------+-------+-------+--------+--------+---------+....+--------+
1
1
2
4
variable
1
(if granted, SOCKS server makes connection to the destination server.)
Reply(from SOCKS server to client) :
+---- -+-----+-------+------- +-------+-------+
| VN | CD | DSTPORT |
# of bytes:

DSTIP
+----- +-----+-------+------ -+-------+-------+
1
1
2
|
4
(SOCKS server closes the connection if reject, or ready relay data on both
directions)
V4 – BIND request & reply

Request(from client to let SOCKS server prepare inbound connection):
+------+-----+-------+-------+-------+--------+--------+---------+....+--------+
| VN | CD | DSTPORT |
DSTIP
|
USERID
|NULL|
+------+-----+-------+-------+-------+--------+--------+---------+....+--------+
# of bytes:

1
1
2
4
variable
Reply(from SOCKS server to client):
+---- -+-----+-------+------- +-------+-------+
| VN | CD | DSTPORT |
DSTIP
|
+----- +-----+-------+------ -+-------+-------+
# of bytes:

1
1
2
4
bind(), getsockname(), listen(), send IP and port to app., accept().
1
V4 Extension


It eliminates the requirement for SOCKSv4 clients to
resolve internal and external domain names.
Appending the unresolved domain names to the
SOCKSv4 client requests, SOCKSv4 servers can
attempt to resolve domain names.
+
+-----+----+------+-----+-----+-----+-----+----+---+---+-------+----+-----+-----+-------
| VN | CD | DSTPORT| DSTIP 0.0.0.x | USERID |NULL| HOSTNAME
|NULL|
+-----+----+------+-----+-----+-----+-----+----+---+---+-------+----+-----+-----+------+
# of bytes: 1
1
2
4
variable
1
variable
1
V4 – How it is plugged in (UNIX)




The SOCKS client replace calls to the socket
functions such as connect(), getsocketname(),
bind(), accept(), listen() and select() - with its own
versions of these functions.
Makefile of the program used to compile the
network client program is modified.
The resulting program is linked to the SOCKS
library.
The SOCKS library intercepts the connection
attempt and opens up a connection to the SOCKS
server.
V4 Weakness


Lack of strong authentication.
The requirement to recompile
applications with SOCKSv4 client library.
SOCKS v5 (rfc 1928) – New Functions

Authentication
Encompass domain name and IPv6 address.

Support UDP-based applications

V5 - Authentication Method Negotiation 1



The application client declares to the SOCKSv5 server
the authentication methods it can support
The SOCKSv5 server sends a message to the client
announcing the method the client should use
The SOCKSv5 server determines the authentication
method based on the security policy defined in the
SOCKSv5 server's configuration. If the client's
declared methods fail to meet the security
requirement, the SOCKSv5 server drops
communication
V5 - Authentication Method Negotiation 2
+------+------------------+----------------+
| VER | NMETHODS | METHODS |
+------+------------------+----------------+
| 1 |
1
| 1 to 255
+------+---------- --------+---------------+
|
+------+-------------+
|VER | METHOD|
+------+-------------+
| 1 |
1
+------+-------------+
The values currently defined for METHOD are:
X'00' NO AUTHENTICATION REQUIRED
X'01' GSSAPI·
X'02' USERNAME/PASSWORD·
X'03' CHAP·
X'04' to X'7F' IANA ASSIGNED·
X'80' to X'FE' RESERVED FOR PRIVATE METHODS·
X'FF' NO ACCEPTABLE METHODS
|
Username/Password Authentication for SOCKS v5.


Defined in RFC 1929
Consists of two simple messages


From the client to the SOCKS server stating the
username and password to use
From the server to the client, stating whether the
authentication succeeded or not.
GSS-API Authentication Method for SOCKS v5




Defined in RFC 1961.
GSS-API: generic security service API.
Establishing a GSS-API security context to
encapsulates negotiation protocol for mechanism
selection and the agreement of security service
options.
GSS-API per-message protection calls encapsulate
TCP/UDP traffic between client and server.
V5 –Domain Name and IPv6 Address.
Request & Reply:
+------+------+-------+--------- +-----------------+---------------+
| VER | REP | RSV | ATYP | BND. ADDR | BND.PORT|
+------+------+-------+--------- +-----------------+---------------+
| 1 | 1 |x’00’|
1
| variable
|
2
+------+------+-------+--------- +-----------------+---------------+
The values currently defined for ATYP are:
X'01' IP v4 address
X'03' DOMAINNAME
X'04' IP v6 address
|
V5 – Support UDP Association




UDP association creates a virtual proxy circuit for traversing
UDP-based application data.
The proxy circuit for UDP is a pair of addresses from the
communication endpoints that send and receive datagrams
UDP headers encapsulate application data including the
destination address of a datagram.
UDP request header:
+------+---------+---------+----------------+----------------+------------+
| RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+------+---------+---------+----------------+----------------+------------+
| 2 |
1 |
1
| Variable |
2
| Variable |
+------+---------+---------+----------------+----------------+------------+
Control Flow of SOCKS (v4 & v5)
Summary 1

A single communication protocol
authenticates users and establishes the
communication channel

transfers user information from the SOCKS client
to the SOCKS server for user authentication
authenticates the user and the channel

guarantees the integrity of TCP and UDP channels

Summary 2

Application-Independent Proxy


It establishes communication channels, and
manages and protects the channel for any
application.
Can protect new applications without requiring
additional development.
Summary 3

Flexible protection through a variety of access control
policies


SOCKS delivers TCP and UDP connections through a proxy
mechanism at the TCP/UDP layer, therefore it works with
any application, and virtually all IP layer technologies, such
as firewalls, NAT, and private IP.
SOCKS adds the flexibility to manage the network through
access control policies based on user, application, and time,
in addition to source and destination addresses.
Summary 4

Bi-directional proxy support


SOCKS identifies communication targets through
domain names, overcoming the private IP address
restrictions.
SOCKS can also use domain names to establish
communication between separate LANs with
redundant IP addresses.
Conclusion – SOCKS is widely used…




As a network firewall
As a generic application proxy
In virtual private networks(VPN).
For extranet applications.
References













http://archive.socks.permeo.com/protocol/socks4.protocol
http://socks.permeo.com/protocol/socks4a.protocol
http://www.ietf.org/rfc/rfc1928.txt
http://www.ietf.org/rfc/rfc1929.txt
http://www.ietf.org/rfc/rfc1961.txt
http://www.ietf.org/rfc/rfc3089.txt
http://archive.socks.permeo.com/draft/draft-ietf-aft-socks-pro-v504.txt
http://www.answers.com/topic/socks
http://www2.rad.com/networks/2005/anonym/page325.htm
http://www.socks.permeo.com/AboutSOCKS/SOCKSOverview.a
sp
http://www.unix.org.ua/orelly/networking/puis/ch22_04.htm
http://www.clipcode.org/messaging/socks.html
http://medialab.di.unipi.it/doc/JNetSec/jns_ch12.htm
Thank You !
Questions?