slococo-uni
/
bproxy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix some bugs 

Co-authored-by: Ezequiel Bellver <ebellver@itba.edu.ar>
Co-authored-by: Juan Barmasch <jbarmasch@itba.edu.ar>
This commit is contained in:
Santiago Lo Coco 2022-06-21 07:56:35 -03:00
parent b503ad1204
commit 7de6cbae60
4 changed files with 0 additions and 892 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

231
docs/enunciado.txt
View File

@ -1,231 +0,0 @@
May 24, 2022
Trabajo Práctico Especial 2022/1
Revisión 0
Resumen
Este documento describe el Trabajo Especial de la materia Protocolos
de Comunicación para la cursada del primer cuatrimestre del año 2022.
En su ejecución los alumnos DEBEN demostrar habilidad para la
programación de aplicaciones cliente/servidor con sockets, la
comprensión de estándares de la industria, y la capacidad de diseñar
protocolos de aplicación.
Terminología
Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO
DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL"
en este documento serán interpretadas como se describe en el RFC 2119
[RFC2119].
Tabla de Contenidos
1. Requerimientos Funcionales . . . . . . . . . . . . . . . . . 1
2. Requerimientos No Funcionales . . . . . . . . . . . . . . . . 2
3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
4.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Requerimientos Funcionales
El objetivo del trabajo es implementar un servidor proxy para el
protocolo SOCKSv5[RFC1928].
El servidor DEBE
[X] 1. atender a múltiples clientes en forma concurrente y simultánea
(al menos 500).
[X] 2. soportar autenticación usuario / contraseña [RFC1929].
[X] 3. soportar de mínima conexiones salientes a a servicios TCP a
direcciones IPv4, IPV6, o utilizando FQDN que resuelvan
cualquiera de estos tipos de direcciones.
[X] 4. ser robusto en cuanto a las opciones de conexión (si se utiliza
un FQDN que resuelve a múltiples direcciones IP y una no está
disponible debe intentar con otros).
[] 5. reportar los fallos a los clientes usando toda la potencia del
protocolo.
[X] 6. implementar mecanismos que permitan recolectar métricas que
ayuden a monitorear la operación del sistema.
[X]A. cantidad de conexiones históricas
[X]B. cantidad de conexiones concurrentes
[X]C. cantidad de bytes transferidos
D. cualquier otra métrica que considere oportuno para el
entendimiento del funcionamiento dinámico del sistema
Las métricas PUEDEN ser volátiles (si se reinicia el servidor las
estadísticas pueden perderse).
[X] 7. implementar mecanismos que permitan manejar usuarios cambiar la
configuración del servidor en tiempo de ejecución sin reiniciar
el servidor. Las diferentes implementaciones PUEDEN decidir
disponibilizar otros cambios de ejecución en tiempo de ejecución
de otras configuraciones (memoria utilizada en I/O, timeouts,
etc).
[X] 8. implementar un registro de acceso que permitan a un administrador
entender los accesos de cada uno de los usuarios. Pensar en el
caso de que llega una queja externa y el administrador debe saber
quien fue el que se conectó a cierto sitio web y cuando.
[X] 9. monitorear el tráfico y generar un registro de credenciales de
acceso (usuarios y passwords) de forma similar a ettercap por lo
menos para protocolo POP3.
2. Requerimientos No Funcionales
Adicionalmente, la implementación DEBE
[X] 1. Estar escritos en el lenguaje de programación C, específicamente
con la variante C11 (ISO/IEC 9899:2011).
[X] 2. Utilizar sockets en modo no bloqueante multiplexada.
[] 3. Tener en cuenta todos los aspectos que hagan a la buena
performance, escalabilidad y disponibilidad del servidor. Se
espera que se maneje de forma eficiente los flujos de información
(por ejemplo no cargar en memoria mensajes muy grandes, ser
eficaz y eficiente en el intérprete de mensajes). El informe
DEBE contener información sobre las pruebas de stress. Algunas
preguntas interesantes a responder son:
* ¿Cual es la máxima cantidad de conexiones simultáneas que
soporta?
* ¿Cómo se degrada el throughput?
[X] 4. Seguir los lineamientos de IEEE Std 1003.1-2008, 2016 Edition /
Base definitions / 12. Utility Conventions [1] a menos que se
especifique lo contrario: Esto se refiere a cómo manejar
argumentos de línea de comandos, parámetros, etc
5. Deberá documentar detalladamente el protocolo de monitoreo y
configuración e implementar una aplicación cliente.
[X] 6. Tanto la aplicación servidor, como la aplicación cliente de
configuración/monitoreo DEBERÁN manejar los argumentos de línea
de comandos de cierta forma uniforme (por ejemplo -c <puerto>
podría especificar el puerto utilizado para el protocolo de
configuración/monitoreo). Los detalles de qué parámetros se
deben manejar será publicado en otro documento.
[X] 7. Si bien las programas son pequeños podrá utilizar librerías o
archivos (fragmento de código) desarrollados por terceros siempre
que se cumplan los siguientes requisitos:
A. La librería o fragmento NO DEBE resolver las cuestiones de
fondo del Trabajo Práctico.
B. La librería o fragmento DEBE tener una licencia aprobada por
la Open Source Initiative [2].
C. El uso de la librería o fragmento DEBE ser aprobada por la
Cátedra.
Para lograr la aprobación un alumno del grupo DEBE publicar una
secuencia en el foro de discusión del trabajo práctico. La
secuencia DEBE describir todos aquellos datos que permitan
identificar a la librería (por ejemplo la versión); su licencia
de esta forma justificando porqué es válido su uso; y el
propósito de su inclusión. En caso de que sea un fragmento de
código debe adjuntarse. Está permitido utilizar código publicado
por los docentes durante la cursada actual, siempre que se
atribuya correctamente.
[] 8. A veces existirán ambigüedades en las especificaciones o
múltiples formas en como se puede resolver o implementar un
problema particular. Por ser una materia de ingeniería se espera
que los alumnos tomen decisiones de diseño razonables en estos
casos. Los alumnos pueden basar sus decisiones en lo que conoce
de ante mano de la tarea y en los objetivos enumerados en este
documento o demás enunciados. Los docentes pueden darle consejos
sobre las ventajas y desventajas de cada decisiones, pero los
alumnos son los que en última instancia las toman.
3. Evaluación
Cada grupo DEBE entregar todo el material necesario para poder
reproducir el Trabajo Práctico. Como mínimo DEBE contener:
a. Un informe en formato PDF [RFC3778] o text/plain (con
codificación UTF-8) que contenga las siguientes secciones
(respetando el orden):
1. Índice
2. Descripción detallada de los protocolos y aplicaciones
desarrolladas.
3. Problemas encontrados durante el diseño y la implementación.
4. Limitaciones de la aplicación.
5. Posibles extensiones.
6. Conclusiones.
7. Ejemplos de prueba.
8. Guía de instalación detallada y precisa. No es necesario
desarrollar un programa instalador.
9. Instrucciones para la configuración.
10. Ejemplos de configuración y monitoreo.
11. Documento de diseño del proyecto (que ayuden a entender la
arquitectura de la aplicación).
b. Códigos fuente y archivos de construcción
c. Un archivo README en la raíz que describa al menos:
A. la ubicación de todos los materiales previamente enumerados
B. el procedimiento necesario para generar una versión
ejecutable de las aplicaciones
C. la ubicación de los diferentes artefactos generados
D. cómo se debe ejecutar las diferentes artefactos generados (y
sus opciones)
La entrega se realizará por Campus ITBA en la asignación creada para
ello con una fecha de entrega. Se DEBE entregar un tarball que sea
el producto de clonar el repositorio GIT (por lo tanto el repositorio
GIT DEBE contener todos los materiales de entrega), y su historia.
Una vez realizada la entrega los grupos DEBERÁN mostrar el correcto
funcionamiento del sistema con casos de prueba provisto por los
equipos y provistos ese día por la Cátedra.
Para aprobar el Trabajo Práctico se DEBE cumplir TODAS las siguientes
condiciones:
o El material entregado DEBE estar completo (por ejemplo no se puede
corregir si falta el informe o alguna clase)
o Se utilizan únicamente las librería permitidas para los usos
definidos.
o DEBE ser correcta las cuestiones de entradas/salida no bloqueante.
Por ejemplo las lecturas, escrituras y el establecimiento de
nuevas conexiones DEBEN ser mediante suscripciones y no
bloquearse.
o DEBE ser correcta las cuestiones relacionadas a la lectura/
escrituras parciales.
o Sumar CUATRO puntos de calificación sobre DIEZ puntos posibles.

107
docs/pruebas.txt
View File

@ -1,107 +0,0 @@
0. Precondiciones
# Hostname foo apuntando a servidor http
time curl -s http://foo/1.iso|sha256sum
e260921ef5c7bd5ee2a7b2f2f1156af6483014c73984e4cf37f2b6690e0155e5
# En la terminal donde corramos el curl dejamos configuracion para el cliente
export O="--proxy localhost:1080 --proxy-type socks5 --proxy-auth juan:juan --proxy-dns local"
# sin resoluciones ipv4
export http_proxy=socks5://juan:juan@localhost/
# con resoluciones dns
export http_proxy=socks5h://juan:juan@localhost/
# en la terminal donde corramos el server lo dejamos configurado con usuarios
export OPTS="-u juan:juan -u prueba:prueba"
./socks5d $OPTS
1. Casos
1.1 Defaults bindings
Term A $ ./socks5d $OPTS
Term B $ netstat -nlp|grep socks5d
tcp 0 0 0.0.0.0:1080 0.0.0.0:* LISTEN 8082/./socks5d
tcp6 0 0 :::1080 :::* LISTEN 8082/./socks5d
sctp 127.0.0.1:8080 LISTEN 8082/./socks5d
1.2 Cambio de bindings
Term A $ ./socks5d -p1111 -P 9091 -l ::1 -L0.0.0.0
Term B $ netstat -nlp|grep socks5d
tcp6 0 0 ::1:1111 :::* LISTEN 8235/./socks5d
sctp 0.0.0.0:9091 LISTEN 8235/./socks5d
1.3 Proxy una conexión por vez
Medir caso base $ time curl http://foo/1.iso|md5sum
Term B $ curl http://foo/1.iso|md5sum
Verificar integridad y velocidad
1.4 Proxy 3 conexiones
Term B $ curl http://foo/1.iso|md5sum
Term C $ curl http://foo/1.iso|md5sum
Term D $ curl http://foo/1.iso|md5sum
1.5 Desconexión repentina cliente
Durante la transferencia matar curl
$ curl http://foo/1.iso|md5sum
verificar que no se queda colgado. top.
1.6 Desconexion repentina server
Durante la transferencia matar curl
$ curl http://foo/1.iso|md5sum
$ sudo /etc/init.d/nginx stop
1.7 Origin server (IPV4) no presta servicio
$ curl 'http://127.0.0.1:3333'
1.8 Origin server (IPV6) no presta servicio
$ curl 'http://[::1]:3333'
1.9 Falla resolución de nombres
$ curl 'http://xxxxxxxxxxx/'
1.10 Comportamiento origin server resuelve DNS IPV6
$ curl http://ipv6.leak.com.ar/
1.11 Origin server con múltiples direcciones IP (una falla)
$ dig +short tpe.proto.leak.com.ar
240.0.0.1
127.0.0.1
$ curl http://tpe.proto.leak.com.ar/
1.12 Agnostico del protocolo
Term B: stty -icanon && nc -l 9090
Term C: stty -icanon && nc $O localhost 9090
1.13 Probar enviarle http
http_proxy="" curl http://127.0.0.1:1080/1.iso
ó
stty -icanon && nc localhost 1080
1.14 desde el browser
no logrue que el chrome funcione con user pass
estos dos son interesante.
https://http1.golang.org/gophertiles?latency=0
https://http2.golang.org/gophertiles?latency=0
http://www.http2demo.io/
1.15 Password disector
con nc

466
docs/rfc1928.txt
View File

@ -1,466 +0,0 @@
SOCKS Protocol Version 5
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Acknowledgments
This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4 [1]. This new protocol stems from
active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
Ganis: International Business Machines.
1. Introduction
The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network,
such as the INTERNET is becoming increasingly popular. These
firewall systems typically act as application-layer gateways between
networks, usually offering controlled TELNET, FTP, and SMTP access.
With the emergence of more sophisticated application layer protocols
designed to facilitate global information discovery, there exists a
need to provide a general framework for these protocols to
transparently and securely traverse a firewall.
Leech, et al Standards Track [Page 1]
RFC 1928 SOCKS Protocol Version 5 March 1996
There exists, also, a need for strong authentication of such
traversal in as fine-grained a manner as is practical. This
requirement stems from the realization that client-server
relationships emerge between the networks of various organizations,
and that such relationships need to be controlled and often strongly
authenticated.
The protocol described here is designed to provide a framework for
client-server applications in both the TCP and UDP domains to
conveniently and securely use the services of a network firewall.
The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide network-
layer gateway services, such as forwarding of ICMP messages.
2. Existing practice
There currently exists a protocol, SOCKS Version 4, that provides for
unsecured firewall traversal for TCP-based client-server
applications, including TELNET, FTP and the popular information-
discovery protocols such as HTTP, WAIS and GOPHER.
This new protocol extends the SOCKS Version 4 model to include UDP,
and extends the framework to include provisions for generalized
strong authentication schemes, and extends the addressing scheme to
encompass domain-name and V6 IP addresses.
The implementation of the SOCKS protocol typically involves the
recompilation or relinking of TCP-based client applications to use
the appropriate encapsulation routines in the SOCKS library.
Note:
Unless otherwise noted, the decimal numbers appearing in packet-
format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X'hh' is used to denote the value of the single octet in that
field. When the word 'Variable' is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
3. Procedure for TCP-based clients
When a TCP-based client wishes to establish a connection to an object
that is reachable only via a firewall (such determination is left up
to the implementation), it must open a TCP connection to the
appropriate SOCKS port on the SOCKS server system. The SOCKS service
is conventionally located on TCP port 1080. If the connection
request succeeds, the client enters a negotiation for the
Leech, et al Standards Track [Page 2]
RFC 1928 SOCKS Protocol Version 5 March 1996
authentication method to be used, authenticates with the chosen
method, then sends a relay request. The SOCKS server evaluates the
request, and either establishes the appropriate connection or denies
it.
Unless otherwise noted, the decimal numbers appearing in packet-
format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X'hh' is used to denote the value of the single octet in that
field. When the word 'Variable' is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
The client connects to the server, and sends a version
identifier/method selection message:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The
NMETHODS field contains the number of method identifier octets that
appear in the METHODS field.
The server selects from one of the methods given in METHODS, and
sends a METHOD selection message:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
If the selected METHOD is X'FF', none of the methods listed by the
client are acceptable, and the client MUST close the connection.
The values currently defined for METHOD are:
o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS
The client and server then enter a method-specific sub-negotiation.
Leech, et al Standards Track [Page 3]
RFC 1928 SOCKS Protocol Version 5 March 1996
Descriptions of the method-dependent sub-negotiations appear in
separate memos.
Developers of new METHOD support for this protocol should contact
IANA for a METHOD number. The ASSIGNED NUMBERS document should be
referred to for a current list of METHOD numbers and their
corresponding protocols.
Compliant implementations MUST support GSSAPI and SHOULD support
USERNAME/PASSWORD authentication methods.
4. Requests
Once the method-dependent subnegotiation has completed, the client
sends the request details. If the negotiated method includes
encapsulation for purposes of integrity checking and/or
confidentiality, these requests MUST be encapsulated in the method-
dependent encapsulation.
The SOCKS request is formed as follows:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
The SOCKS server will typically evaluate the request based on source
and destination addresses, and return one or more reply messages, as
appropriate for the request type.
Leech, et al Standards Track [Page 4]
RFC 1928 SOCKS Protocol Version 5 March 1996
5. Addressing
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
the type of address contained within the field:
o X'01'
the address is a version-4 IP address, with a length of 4 octets
o X'03'
the address field contains a fully-qualified domain name. The first
octet of the address field contains the number of octets of name that
follow, there is no terminating NUL octet.
o X'04'
the address is a version-6 IP address, with a length of 16 octets.
6. Replies
The SOCKS request information is sent by the client as soon as it has
established a connection to the SOCKS server, and completed the
authentication negotiations. The server evaluates the request, and
returns a reply formed as follows:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o REP Reply field:
o X'00' succeeded
o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset
o X'03' Network unreachable
o X'04' Host unreachable
o X'05' Connection refused
o X'06' TTL expired
o X'07' Command not supported
o X'08' Address type not supported
o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
Leech, et al Standards Track [Page 5]
RFC 1928 SOCKS Protocol Version 5 March 1996
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
Fields marked RESERVED (RSV) must be set to X'00'.
If the chosen method includes encapsulation for purposes of
authentication, integrity and/or confidentiality, the replies are
encapsulated in the method-dependent encapsulation.
CONNECT
In the reply to a CONNECT, BND.PORT contains the port number that the
server assigned to connect to the target host, while BND.ADDR
contains the associated IP address. The supplied BND.ADDR is often
different from the IP address that the client uses to reach the SOCKS
server, since such servers are often multi-homed. It is expected
that the SOCKS server will use DST.ADDR and DST.PORT, and the
client-side source address and port in evaluating the CONNECT
request.
BIND
The BIND request is used in protocols which require the client to
accept connections from the server. FTP is a well-known example,
which uses the primary client-to-server connection for commands and
status reports, but may use a server-to-client connection for
transferring data on demand (e.g. LS, GET, PUT).
It is expected that the client side of an application protocol will
use the BIND request only to establish secondary connections after a
primary connection is established using CONNECT. In is expected that
a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND
request.
Two replies are sent from the SOCKS server to the client during a
BIND operation. The first is sent after the server creates and binds
a new socket. The BND.PORT field contains the port number that the
SOCKS server assigned to listen for an incoming connection. The
BND.ADDR field contains the associated IP address. The client will
typically use these pieces of information to notify (via the primary
or control connection) the application server of the rendezvous
address. The second reply occurs only after the anticipated incoming
connection succeeds or fails.
Leech, et al Standards Track [Page 6]
RFC 1928 SOCKS Protocol Version 5 March 1996
In the second reply, the BND.PORT and BND.ADDR fields contain the
address and port number of the connecting host.
UDP ASSOCIATE
The UDP ASSOCIATE request is used to establish an association within
the UDP relay process to handle UDP datagrams. The DST.ADDR and
DST.PORT fields contain the address and port that the client expects
to use to send UDP datagrams on for the association. The server MAY
use this information to limit access to the association. If the
client is not in possesion of the information at the time of the UDP
ASSOCIATE, the client MUST use a port number and address of all
zeros.
A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates.
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
fields indicate the port number/address where the client MUST send
UDP request messages to be relayed.
Reply Processing
When a reply (REP value other than X'00') indicates a failure, the
SOCKS server MUST terminate the TCP connection shortly after sending
the reply. This must be no more than 10 seconds after detecting the
condition that caused a failure.
If the reply code (REP value of X'00') indicates a success, and the
request was either a BIND or a CONNECT, the client may now start
passing data. If the selected authentication method supports
encapsulation for the purposes of integrity, authentication and/or
confidentiality, the data are encapsulated using the method-dependent
encapsulation. Similarly, when data arrives at the SOCKS server for
the client, the server MUST encapsulate the data as appropriate for
the authentication method in use.
7. Procedure for UDP-based clients
A UDP-based client MUST send its datagrams to the UDP relay server at
the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
request. If the selected authentication method provides
encapsulation for the purposes of authenticity, integrity, and/or
confidentiality, the datagram MUST be encapsulated using the
appropriate encapsulation. Each UDP datagram carries a UDP request
header with it:
Leech, et al Standards Track [Page 7]
RFC 1928 SOCKS Protocol Version 5 March 1996
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
The fields in the UDP request header are:
o RSV Reserved X'0000'
o FRAG Current fragment number
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port
o DATA user data
When a UDP relay server decides to relay a UDP datagram, it does so
silently, without any notification to the requesting client.
Similarly, it will drop datagrams it cannot or will not relay. When
a UDP relay server receives a reply datagram from a remote host, it
MUST encapsulate that datagram using the above UDP request header,
and any authentication-method-dependent encapsulation.
The UDP relay server MUST acquire from the SOCKS server the expected
IP address of the client that will send datagrams to the BND.PORT
given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
arriving from any source IP address other than the one recorded for
the particular association.
The FRAG field indicates whether or not this datagram is one of a
number of fragments. If implemented, the high-order bit indicates
end-of-fragment sequence, while a value of X'00' indicates that this
datagram is standalone. Values between 1 and 127 indicate the
fragment position within a fragment sequence. Each receiver will
have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
fragments. The reassembly queue must be reinitialized and the
associated fragments abandoned whenever the REASSEMBLY TIMER expires,
or a new datagram arrives carrying a FRAG field whose value is less
than the highest FRAG value processed for this fragment sequence.
The reassembly timer MUST be no less than 5 seconds. It is
recommended that fragmentation be avoided by applications wherever
possible.
Implementation of fragmentation is optional; an implementation that
does not support fragmentation MUST drop any datagram whose FRAG
field is other than X'00'.
Leech, et al Standards Track [Page 8]
RFC 1928 SOCKS Protocol Version 5 March 1996
The programming interface for a SOCKS-aware UDP MUST report an
available buffer space for UDP datagrams that is smaller than the
actual space provided by the operating system:
o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller
8. Security Considerations
This document describes a protocol for the application-layer
traversal of IP network firewalls. The security of such traversal is
highly dependent on the particular authentication and encapsulation
methods provided in a particular implementation, and selected during
negotiation between SOCKS client and SOCKS server.
Careful consideration should be given by the administrator to the
selection of authentication methods.
9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
Author's Address
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7
Phone: (613) 763-9145
EMail: mleech@bnr.ca

88
docs/rfc1929.txt
View File

@ -1,88 +0,0 @@
Username/Password Authentication for SOCKS V5
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Introduction
The protocol specification for SOCKS Version 5 specifies a
generalized framework for the use of arbitrary authentication
protocols in the initial socks connection setup. This document
describes one of those protocols, as it fits into the SOCKS Version 5
authentication "subnegotiation".
Note:
Unless otherwise noted, the decimal numbers appearing in packet-
format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X'hh' is used to denote the value of the single octet in that
field. When the word 'Variable' is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
2. Initial negotiation
Once the SOCKS V5 server has started, and the client has selected the
Username/Password Authentication protocol, the Username/Password
subnegotiation begins. This begins with the client producing a
Username/Password request:
+----+------+----------+------+----------+
|VER | ULEN | UNAME | PLEN | PASSWD |
+----+------+----------+------+----------+
| 1 | 1 | 1 to 255 | 1 | 1 to 255 |
+----+------+----------+------+----------+
Leech Standards Track [Page 1]
RFC 1929 Username Authentication for SOCKS V5 March 1996
The VER field contains the current version of the subnegotiation,
which is X'01'. The ULEN field contains the length of the UNAME field
that follows. The UNAME field contains the username as known to the
source operating system. The PLEN field contains the length of the
PASSWD field that follows. The PASSWD field contains the password
association with the given UNAME.
The server verifies the supplied UNAME and PASSWD, and sends the
following response:
+----+--------+
|VER | STATUS |
+----+--------+
| 1 | 1 |
+----+--------+
A STATUS field of X'00' indicates success. If the server returns a
`failure' (STATUS value other than X'00') status, it MUST close the
connection.
3. Security Considerations
This document describes a subnegotiation that provides authentication
services to the SOCKS protocol. Since the request carries the
password in cleartext, this subnegotiation is not recommended for
environments where "sniffing" is possible and practical.
4. Author's Address
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Station C
Ottawa, ON
CANADA K1Y 4H7
Phone: +1 613 763 9145
EMail: mleech@bnr.ca