What is the difference between HTTP proxies and Socks5 proxies. Universal proxy server

When working with a proxy, it is very important to choose correct type proxy for your tasks to avoid possible problems and achieve your goals. The most commonly used are HTTP proxies and Socks5 proxies. The differences between them lie in the degree of anonymity, the protocol used, the method of data transmission used when working as a proxy, as well as in some additional functions. Let's look at each type of proxy separately.

Features of HTTP proxy

Let's start with the HTTP proxy. During their work, they use the HTTP protocol, which is intended for visiting sites, downloading and transferring files, and when working with some programs that use this protocol to connect through a proxy. Requests made when working with HTTP proxy servers are not sent directly, but use the proxy server as an intermediary, sending requests on its behalf.

Also in the HTTP proxy protocol, caching is available, which speeds up page loading through the use of saved files, as well as monitoring and filtering network traffic, setting speed limits, blocking unwanted resources, collecting statistics by saving logs, etc.

Proxies of this protocol differ in the degree of anonymity. Stand out following types HTTP proxy for anonymity:

Transparent proxies that do not mask the real IP address, and also do not hide the fact that a proxy server is used to access the resource. Such proxies are rarely used, mainly to redirect the user to another proxy server,

Anonymous Proxy. They transmit information that proxies are used, however, your IP address is masked and replaced with another IP address, providing a reliable level of security.

Elite proxies. They hide the use of proxies and also reliably mask the IP address, which makes them the most secure among HTTP proxies. The server you are trying to access will assume that your connection is direct, without using a proxy server.

Separately, it is worth highlighting HTTPS proxies that use SSL protocol. They are a subtype of the HTTP protocol that uses a secure connection. Network traffic transmitted by these proxies is securely encrypted, which guarantees highest level anonymity. As a rule, such proxies are used to ensure the security of banking networks, in commercial organizations to create secure corporate networks and in other connections that require security. Other features are the same as those of the HTTP protocol.

Features of Socks5 proxy

Another protocol that is popular among users is Socks5. Proxy servers working with this protocol are initially anonymous because they allow network traffic in its pure form, without revealing HTTP headers. Therefore, the server you are trying to access will not know that you are using a proxy server, and will not receive your IP address.

Socks5 proxy, supports the following network protocols: HTTP, HTTPS, FTP and their features: caching, SSL connection,authentication. In addition, Socks5 protocol proxies use UDP and TPC connections, which expands their scope of application and makes them the most functional of modern proxy servers. Initially, the Socks5 protocol was intended to work with software. For this reason, most programs support this protocol for connecting via a proxy. Socks5 proxy servers also have a nice feature that allows you to build chains of proxy servers, which is useful for solving some problems when working on the Internet.

If you compare HTTP and Socks5 proxies, it is preferable to use the latter. Since they are more anonymous, they support more features, and also work with any sites and programs that support connection through a proxy. You can visit our website by placing an order in your personal account.

Anonymity on the Internet is not a new topic. And you probably installed a program like A4Proxy, SocksChain on your computer
and the like. Personally, I don’t like it when you need some kind of separate program to work with proxies. Firstly
it’s ugly when there are a lot of windows on the taskbar or tray icons, secondly, these programs require cracks, and they
I’m too lazy to look :) That’s why I wrote classes to support SOCKS5 servers, which I can now use
in some of your programs. And now I want to tell everyone how to do it.

Which servers and which protocols we can access through a proxy depends on
the type of this proxy, i.e. the protocol by which we access it. There are several types of proxies:
HTTP proxies, SOCKS4, SOCKS5, SSL CONNECT, etc. HTTP proxies are the most common, they are the easiest to find on the Internet, but they only work with HTTP, moreover
they can insert the client’s address into the request headers, that is, be
not anonymous. SOCKS protocol most notable in that it encapsulates not application protocols, but
transport layer, i.e. TCP/IP and UDP/IP. Since only these protocols are used to work on the Internet,
through SOCKS you can work with any servers, including the same SOCKS and,
thus, organize chains of SOCKS servers. For the same reason, ALL SOCKS servers are anonymous - impossible
transmit at the TCP/IP and UDP/IP level Additional information without disrupting the work of the superior
protocol.

We will focus on the SOCKS5 protocol. Its description is in
. For SOCKS5 the standard port is 1080, but, however, this
No one pays much attention to the standard. Each SOCKS connection goes through an authentication stage, if required, then the client
sends a command. The command can be one of three:
CONNECT - outgoing TCP connection with specified address. We will look at using this command
in more detail, since it is needed most often. BIND - open a port (the server selects a port and sends the address and port to the client) and accept a TCP connection.
The server may need to know who will be connecting. In this case, you need to pass on this information. UDP ASSOCIATE - open a UDP port (the server selects the port). Data intended for the end
host and data from it also travels via UDP. Data in SOCKS5 is transmitted in binary form, and not in text form, as in HTTP, SMTP, POP3, etc.

Protocol description

Having connected to the server, the client sends a packet indicating the protocol version and supported
authentication methods. This package has the following format:

BYTE Version;
BYTE nMethods;
BYTE methods

The version must be 5. Each methods element defines not only the authentication method, but also the method of data encryption,
if it is used. The server chooses one of these methods. You can specify any number of methods, but if the server does not require authentication, then no methods
other than 0x00 (use neither authentication nor encryption) will not be required. In response, the server sends a packet with the following content:

BYTE Version
BYTE method

where method is the method chosen by the server or 0xFF (none of the proposed methods are supported). If the method is 0x00, then you can immediately send the command.

The command packet has the following format:

BYTE Version; // 5
BYTE Cmd ; // 1 — CONNECT
BYTE Reserved; // 0

BYTE addr;
WORD port; // Bytes in network order, i.e. htons(Port);

If a domain name is used, the length byte comes first, and then the string without the terminating null.

The server sends a response:

BYTE Version; // 5
BYTE Rep ; // 0 — Ok
BYTE Reserved; // 0
BYTE AType; // 1 - IPv4; 3 - domain name; 4 - IPv6
BYTE addr;
WORD port;

Here address and port are the address and port visible to the host. As a rule, the IP address is returned, not the domain
Name. This address may differ from the one at which we access the server, especially if the server
used for its intended purpose, i.e. to exit from the local area to the Internet. If Rep is not zero, i.e. an error, then close the connection, in
otherwise we work with the host. We don't use encryption, so we simply send and receive data as with a normal connection. If one of the parties closes the connection to the socks server, it will immediately close the connection to the other
side. One socks connection encapsulates one TCP connection or attempt to establish one,
so if you use socks for anonymous port scanning, then this
the procedure may take half a day.

Coding

Since socks encapsulates TCP, it makes sense to make the socks connection class derive from
socket class, but MFC's CSocket is not suitable, because he has all the methods
not virtual. Let's write our own socket class and call it, say, CTSocket

#include

class CTSocket
{
public:





virtual void Close();
virtual unsigned long GetHost(); // Find out your address. This may also be needed.

private:
SOCKET sock;
};

Everyone can write the implementation of this class themselves (who doesn’t know how, RTFM MSDN), so I won’t write it
consider. Now let's write a socks connection class. It will support only the most necessary set
functions: only the CONNECT command is supported, authentication and SOCKS server are not supported
is specified only by IP address, not domain name. More can’t fit in one article.

Class CSocksSocket: public CTSocket
{
public:
virtual BOOL CreateSocket();
virtual BOOL Connect(unsigned long ip, unsigned short port);
virtual BOOL Connect(LPCSTR name, unsigned short port);
virtual int Send(const char* str, int len);
virtual int Recv(char* buf, int max);
virtual BOOL Close();
virtual unsigned long GetHost();

CTSocket* pSocket;
unsigned long socks_ip;
unsigned short socks_port;

private:
char buffer; // This size is definitely enough
unsigned long l_ip; // Address returned by the function
GetHost()
};

// Implementation
BOOL CSocksSocket::CreateSocket()
{
if (!pSocket->CreateSocket()) return FALSE;
if (!pSocket->Connect(socks_ip, socks_port)) return FALSE;
buffer = 5; //Ver
buffer = 1; // 1 method
buffer = 0; // no authentication
pSocket->Send(buffer, 3);
int n = pSocket->Recv(buffer, 2);
if (n != 2) return FALSE;
method 0 not supported
return TRUE;
}

BOOL CSocksSocket::Connect(unsigned long ip, unsigned short port)
{
buffer = 5; //Ver
buffer = 1; // CONNECT
buffer = 0; //Reserved
buffer = 1; //IPv4
*((unsigned long*)(buffer + 4)) = ip;
*((unsigned short*)(buffer + 8)) = port;
pSocket->Send(buffer, 10);
int n = pSocket->Recv(buffer, 10);
if (n != 10) return FALSE;
if (buffer != 0) return FALSE; // Can't connect

return TRUE;
}

BOOL CSocksSocket::Connect(LPCSTR name, unsigned short port)
{
buffer = 5;
buffer = 1;
buffer = 0;
buffer = 3; // Domain name
int m = strlen(name);
buffer = m; // Length byte
memcpy(buffer+5, name, m); //Copying a string without a terminating null
*((unsigned short*)(buffer + 5 + m)) = port;
pSocket->Send(buffer, m + 7);
int n = pSocket->Recv(buffer, 10);
if (n != 10) return FALSE;
if (buffer != 0) return FALSE;
if (buffer != 1) return FALSE; //We will demand that they tell us the IP, and not something else.
l_ip = *((unsigned long*)(buffer + 4));
return TRUE;
}

int CSocksSocket::Send(const char* str, int len)
{
return pSocket->Send(str, len);
}

int CSocksSocket::Recv(char* buf, int max)
{
return pScoket->Recv(buf, max);
}

void CSocksSocket::Close()
{
pSocket->Close();
}

unsigned long CSocksSocket::GetHost()
{
return l_ip;
}

//Well, now the test program
void main()
{
WSADATA wsadata;
CTSocket tsock;
CSocksSocket ssock(&tsock);

WSAStartup(MAKEWORD(2,2), &wsadata);

ssock.socks_ip = inet_addr("10.10.10.10"); // Enter here required address
ssock.socks_port = 1080; //Enter the port here

if (!ssock.CreateSocket()) return; // Can't connect to socks
// or authentication required
if (!ssock.Connect("www.mail.ru", htons(80))) return; // www.mail.ru
// is inaccessible
LPSTR q = "HEAD / HTTP/1.1\xD\xAHost: www.mail.ru:80\xD\xAUser-Agent: xakep\xD\xA\xD\xA";
ssock.Send(q, strlen(q));

char buf;
int n = ssock.Recv(buf, 1000);
buf[n] = 0;
printf("%s", buf);

SOCKS, short for “SOCKetS” (sockets, sockets), is designed to enable client/server applications in the TCP and UDP domains to conveniently and securely use firewall services. It gives users the ability to bypass an organization's firewall and gain access to resources located on the Internet. SOCKS is an “application layer middleman”: it interacts with common via network means(for example, Telnet and the Netscape browser) and, using a central server (proxy server), communicates with other central computers on behalf of your computer.

SOCKS was developed many years ago by Dave Koblas of SGI, and today the code is available for free on the Internet. Since its initial release, this code has gone through several major modifications, but each of them was distributed completely free of charge. SOCKS version 4 addresses the issue of insecure firewall traversal by TCP-based client/server applications, including Telnet, FTP, and popular data protocols such as HTTP, Wide Area Information Server (WAIS) and GOPHER. SOCKS version 5, RFC 1928, is a further extension of SOCKS version 4. It includes UDP, extends the overall framework to allow for powerful generalized authentication schemes, and extends the addressing system to include domain name and IP v6 addresses.

It is currently proposed to create a mechanism to control incoming and outgoing IP multicast messages that pass through the firewall. This is achieved by defining extensions to the existing SOCKS V.5 protocol, which creates the basis for authenticated firewall transition by TCP and UDP unicast user traffic. However, due to the fact that UDP support in current version SOCKS V.5 has scalability issues and other shortcomings (and should definitely be resolved before moving to multicast), extensions are defined in two ways: as UDP base extensions and as UDP multicast extensions.

The functioning of SOCKS is to replace standard network system calls enclosed them special versions. These new system calls establish communication with SOCKS proxy server(which is configured by the user himself in the application or system file configuration) by connecting to a well-known port (usually port 1080/TCP). After establishing a connection with the SOCKS server, the application sends the server the machine name and port number to which the user wants to connect. The SOCKS server actually establishes a connection with the remote central computer, and then transparently transfers data between the application and the remote machine. In this case, the user does not even suspect that there is a SOCKS server in the communication channel.

The difficulty with using SOCKS is that someone has to do the work of replacing the network system calls with SOCKS versions (this process is usually called “SOCKS-ifying” the application). Fortunately, most ordinary network applications(Telnet, FTP, finger, whois) are already SOCKS-ified, and many vendors include SOCKS support in their commercial applications. Additionally, SOCKS V.5 includes these routines in its shared library: on some systems (such as Solaris machines), you can automatically SOCKS your application by putting the SOCKS shared library in front of “shared libc” in your library search string ( environment variable LD__LIBRARY_PATH on Solaris systems).

Such a proxy server controls the client's rights to access external resources and sends the request to the server. SOCKS can also be used in the opposite way, allowing external clients to connect to servers behind firewall(firewall).

Unlike HTTP proxy servers, SOCKS transmits all the data from the client without adding anything from itself, that is, from the point of view of the end server, the SOCKS proxy is a regular client. SOCKS is more universal - it does not depend on specific application layer protocols (layer 7 of the OSI model) and is based on the TCP/IP standard - the layer 4 protocol. But the HTTP proxy caches data and can more carefully filter the content of the transmitted data.

This protocol was developed by David Koblas, a system administrator at MIPS Computer Systems. After MIPS became part of Silicon Graphics (SGI) that year, Koblas gave a talk on SOCKS at the Usenix Security Symposium, and SOCKS became publicly available. The protocol was extended to version 4 by Ying-Da Lee of NEC Systems Laboratory.

SOCKS 4 protocol

SOCKS 4 is designed to work through a firewall without authentication for client-server applications running over TCP, such as TELNET, FTP, and popular communication protocols such as HTTP, WAIS, and GOPHER. Essentially, a SOCKS server can be thought of as a firewall that supports the SOCKS protocol.

A typical SOCKS 4 request looks like this (each field is one byte):

Client request to SOCKS Server:

• field 1: SOCKS version number, 1 byte (should be 0x04 for this version)
• field 2: command code, 1 byte:
  • 0x02 = TCP/IP port assignment (binding)
• field 3: port number, 2 bytes
• field 4: IP address, 4 bytes
• field 5: user ID, variable length string, terminated with a null byte (0x00). The field is intended to identify the user (see Ident)

Server response to SOCKS Client:

• field 1: null byte
• field 2: response code, 1 byte:
  • 0x5a = request granted
  • 0x5b = request rejected or invalid
  • 0x5c = The request failed because identd is not running (or is not accessible from the server)
  • 0x5d = The request failed because the client identd could not validate the user ID in the request
• field 3: 2 arbitrary bytes, should be ignored
• field 4: 4 arbitrary bytes, should be ignored

SOCKS 5 protocol

SOCKS 5 extends the SOCKS 4 model by adding UDP support, providing universal schemes strong authentication and extends addressing methods by adding support for domain names and IPv6 addresses. Initial installation The connection now consists of the following:

• The client connects and sends a greeting that includes a list of supported authentication methods
• The server chooses one of them (or sends a request failure response if none of the proposed methods is acceptable)
• Depending on the chosen method, a number of messages may pass between the client and server
• The client sends a connection request, similar to SOCKS 4
• Server responds, similar to SOCKS 4

Authentication methods are numbered as follows:

• 0x00 - no authentication required
• 0x01 - GSSAPI
• 0x02 - username/password
• 0x03-0x7F - reserved by IANA
• 0x80-0xFE - reserved for private use methods

Initial greeting from the client:

• field 2: number of supported authentication methods, 1 byte
• field 3: authentication method numbers, variable length, 1 byte for each supported method

The server reports its choice:

• field 1: SOCKS version, 1 byte (0x05 for this version)
• field 2: selected authentication method, 1 byte, or 0xFF if no acceptable method was proposed

Subsequent identification depends on the chosen method.

Customer Request:

• field 1: SOCKS version number (should be 0x05 for this version)
• field 2: command code, 1 byte:
  • 0x01 = setting up TCP/IP connection
  • 0x02 = TCP/IP port assignment (binding)
  • 0x03 = UDP port association
• field 3: reserved byte, must be 0x00
• field 4: address type, 1 byte:
  • 0x01 = IPv4 address
  • 0x03 = domain name
  • 0x04 = IPv6 address
• field 5: address assignment
  • 4 bytes for IPv4 address
  • 16 bytes for IPv6 address
• field 6: port number, 2 bytes

Server response:

• field 1: SOCKS version number, 1 byte (0x05 for this version)
• field 2: response code, 1 byte:
  • 0x00 = request granted
  • 0x01 = SOCKS server error
  • 0x02 = connection is prohibited by the ruleset
  • 0x03 = network unavailable
  • 0x04 = host unreachable
  • 0x05 = connection refused
  • 0x06 = TTL expired
  • 0x07 = Command not supported / protocol error
  • 0x08 = address type not supported
• field 3: byte reserved, must be 0x00
• field 4: subsequent address type, 1 byte:
  • 0x01 = IPv4 address
  • 0x03 = domain name
  • 0x04 = IPv6 address
• field 5: address assignment
  • 4 bytes for IPv4 address
  • the first byte is the length of the name, followed by the domain name without a terminating null
  • 16 bytes for IPv6 address
• field 6: port number, 2 bytes

Implementations

• Sun Java System Web Proxy Server - caching proxy server for Solaris, Linux, Windows. Supports HTTPS, NSAPI I/O filters, dynamic reconfiguration and reverse proxy.
• DeleGate is a multifunctional application level gateway and proxy server that runs on various platforms. In addition to SOCKS, it also supports HTTP(S), FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, DNS and other protocols.
• 3proxy - lightweight proxy server with SOCKS-proxy support
• WinGate is a multi-protocol proxy server with SOCKS support for Windows.
• OpenSSH allows you to dynamically create tunnels defined through a subset of the SOCKS protocol.

see also

• Tor- anonymous network onion routing, with a SOCKS interface.

Links

• RFC 1928 - SOCKS Protocol Version 5
• RFC 1928 (Russian) - SOCKS 5 Protocol
• RFC 1929 - Username/Password Authentication for SOCKS V5
• RFC 1961 (English) - GSS-API Authentication Method for SOCKS Version 5
• SOCKS: A protocol for TCP proxy across firewalls - SOCKS 4 protocol

Wikimedia Foundation.

2010.

See what "SOCKS" is in other dictionaries: SOCKS - is an Internet protocol

See what "SOCKS" is in other dictionaries: that allows client server applications to transparently use the services of a network firewall. SOCKS is an abbreviation for SOCKetS [ ]… … Wikipedia

- Saltar a navegación, búsqueda SOCKS es un protocolo de Internet que permite a las aplicaciones Cliente servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de SOCKETS . Los clientes que hay detrás… … Wikipedia Español Network protocol that allows the client server applications

transparently use services behind firewalls. SOCKS is short for SOCKetS (sockets). Clients behind a firewall needing access to... ... Wikipedia Socks

transparently use services behind firewalls. SOCKS is short for SOCKetS (sockets). Clients behind a firewall needing access to... ... Wikipedia- im Briefing Room des Weißen Hauses Betty Currie und Socks … Deutsch Wikipedia