SOCKS

1
SOCKS

• Group Challenger
• Member Lichun Zhan

2
Agenda

• Introduction
• SOCKS v4
• SOCKS v5
• Summary
• Conclusion
• References
• Questions

3
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.

4
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.

5
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.

6
Place In OSI Layer
7
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.

8
Introduction Connection Setup
9
Introduction Data Relay
10
SOCKS V4 Three functions

• CONNECTmakes connection requests.
• BIND sets up proxy circuits
• Relays application data

11
V4 CONNECT request reply

• Request(from client to SOCKS server)
• 
  -------------------------------------------
  --------------....--------
• VN CD DSTPORT
  DSTIP USERID NULL
• 
  -------------------------------------------
  --------------....--------
• of bytes 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 DSTIP
• -----
  ------------------ ---------------
• of bytes 1 1
  2 4
• (SOCKS server closes the connection if reject, or
  ready relay data on both directions)
  

12
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
  1
• 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().

13
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

14
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.

15
V4 Weakness

• Lack of strong authentication.
• The requirement to recompile applications with
  SOCKSv4 client library.

16
SOCKS v5 (rfc 1928) New Functions

• Authentication
• Encompass domain name and IPv6 address.
• Support UDP-based applications

17
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

18
V5 - Authentication Method Negotiation 2

• ----------------------------------------
  -------------------
• VER NMETHODS METHODS
  VER METHOD
• ----------------------------------------
  -------------------
• 1 1 1 to 255
  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

19
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.

20
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.

21
V5 Domain Name and IPv6 Address.

• Request Reply
• ----------------------------
  --------------------------------
• VER REP RSV ATYP BND. ADDR
  BND.PORT
• ----------------------------
  --------------------------------
• 1 1 x00 1
  variable 2
• ----------------------------
  --------------------------------
• The values currently defined for ATYP are
• X'01' IP v4 address
• X'03' DOMAINNAME     
• X'04' IP v6 address       

22
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
• --------------------------------
  ------------------------------------

23
Control Flow of SOCKS (v4 v5)
24
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

25
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.

26
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.

27
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.

28
Conclusion SOCKS is widely used

• As a network firewall
• As a generic application proxy
• In virtual private networks(VPN).
• For extranet applications.

29
References

• http//archive.socks.permeo.com/protocol/socks4.pr
  otocol
• 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-a
  ft-socks-pro-v5-04.txt
• http//www.answers.com/topic/socks
• http//www2.rad.com/networks/2005/anonym/page325.h
  tm
• http//www.socks.permeo.com/AboutSOCKS/SOCKSOvervi
  ew.asp
• 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.h
  tm

30
Thank You !

• Questions?