Hispanopedia Wiki
Articulo de referencia

Protocolo de cliente a cliente

El protocolo de cliente a cliente ( CTCP ) es un tipo especial de comunicación entre clientes de Internet Relay Chat (IRC). CTCP es un protocolo común implementado por la mayorí...

Hispanopedia WikiContenido en espanolLectura gratuita

El protocolo de cliente a cliente ( CTCP ) es un tipo especial de comunicación entre clientes de Internet Relay Chat (IRC).

CTCP es un protocolo común implementado por la mayoría de los principales clientes IRC en uso actualmente. [ 1 ] CTCP extiende el protocolo IRC original al permitir que los usuarios consulten a otros clientes o canales, lo que provoca que todos los clientes en el canal respondan con CTCP para obtener información específica. Además, CTCP se puede usar para codificar mensajes que el protocolo IRC original no permitiría enviar a través del enlace, como mensajes que contienen saltos de línea o el valor de byte 0 (NULL). CTCP no establece una conexión directa entre clientes; sin embargo, se usa comúnmente para negociar conexiones DCC .

CTCP permite a los usuarios consultar a un cliente remoto sobre la versión del cliente que están utilizando (a través de CTCP VERSION), o la hora (a través de CTCP TIME), entre otras cosas. También se utiliza para implementar el comando /me (a través de CTCP ACTION).

Historia

ircII fue el primer cliente IRC en implementar los protocolos CTCP y DCC. [ 2 ] El protocolo CTCP fue implementado por Michael Sandrof en 1990 para la versión 2.1 de ircII, [ 3 ] mientras que el protocolo DCC fue implementado por Troy Rollo en 1991 para la versión 2.1.2. [ 4 ]

Estructura

Un mensaje CTCP se implementa como un PRIVMSGo NOTICEdonde el primer y último carácter del mensaje son el valor ASCII 0x01. Además, los caracteres que no estarían permitidos en el protocolo IRC se escapan. Dado que un NOTICEcomo estándar no debería generar una respuesta, los mensajes CTCP se envían como PRIVMSGy la respuesta se implementa con un NOTICEen lugar de un PRIVMSG.

En la mayoría de los clientes, la consulta CTCP se inicia de la siguiente manera:

CTCP <objetivo> <comando> <argumentos>

Donde <target> es el alias o canal de destino, <command> es el comando CTCP (por ejemplo, VERSION), y <arguments> son información adicional que se enviará a <target> .

Comandos comunes de CTCP

Los comandos y respuestas CTCP son específicos del cliente; por lo tanto, dependiendo del cliente IRC, algunos de los siguientes comandos CTCP pueden no generar una respuesta o tendrán un formato diferente al que se muestra aquí.

VERSIÓN

Una CTCP VERSIONsolicitud devolverá el nombre y la versión del cliente IRC que está utilizando el objetivo y, en algunos casos, información técnica como el sistema operativo , la frecuencia de reloj , el fabricante de la CPU y la arquitectura / conjunto de instrucciones de la CPU .

Un ejemplo de respuesta a una CTCP VERSIONsolicitud dirigida a un destinatario que utiliza el cliente HexChat es:

VERSIÓN HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]

TIEMPO

Una CTCP TIMEsolicitud devolverá la hora local del ordenador de destino. Dependiendo del cliente IRC, la respuesta puede consistir en la fecha , la hora (ya sea en formato de 12 horas o de 24 horas ), el año (por ejemplo, 2012) y, a veces, la zona horaria (por ejemplo, EST ).

Un ejemplo de respuesta a una CTCP TIMEsolicitud dirigida a un destinatario que utiliza el cliente ChatZilla es:

HORA Viernes 23 de noviembre de 2012 19:26:42 EST

SILBIDO

Una CTCP PINGsolicitud determina la latencia (ping) entre dos clientes (sin contar el servidor). El CTCP PINGcomando envía un argumento (generalmente) entero (una marca de tiempo ) al cliente de destino; este responde proporcionando exactamente el mismo parámetro numérico. Se calcula la diferencia entre la marca de tiempo original y la actual, y el resultado se muestra al usuario que inició el CTCP PING . Normalmente, se utiliza una marca de tiempo en milisegundos , ya que la mayoría de los usuarios con conexiones a Internet de banda ancha tienen una latencia inferior a 1 segundo.

Un ejemplo CTCP PINGde solicitud dirigida a <nickname> desde el cliente XChat es:

CTCP PING 23152511

Asimismo, el resultado de ejemplo generado a partir de la diferencia (véase más arriba) es:

Respuesta de ping de <nickname>: 0,53 segundos

Chat de DCC

El servicio CHAT permite a los usuarios chatear entre sí a través de una conexión DCC. [ 5 ] El tráfico irá directamente entre los usuarios, y no a través de la red IRC. En comparación con el envío normal de mensajes, esto reduce la carga de la red IRC, permite enviar mayores cantidades de texto a la vez, debido a la falta de control de inundación, y hace que la comunicación sea más segura al no exponer el mensaje a los servidores IRC (sin embargo, el mensaje sigue estando en texto plano ).

El chat DCC se inicia normalmente mediante un protocolo de enlace CTCP . El usuario que desea establecer la conexión envía el siguiente CTCP al destinatario , donde ip y puerto son la dirección IP y el número de puerto del remitente, y se expresan como números enteros. El protocolo es chat para el chat DCC estándar. El receptor puede entonces conectarse al puerto y la dirección IP indicados.DCC CHAT protocolipport

Una vez establecida la conexión, el protocolo utilizado para DCC CHAT es muy simple: los usuarios intercambian mensajes terminados en CRLF . Los mensajes que comienzan con un ASCII 001 (control-A, representado a continuación por [^A] ) y la palabra ACTION , y terminan con otro ASCII 001 , se interpretan como emoticonos: .[^A]ACTION waves goodbye[^A]

Pizarra blanca DCC

Esta es una extensión de DCC CHAT, que permite enviar comandos de dibujo simples, así como líneas de texto. DCC Whiteboard se inicia con un protocolo de enlace similar a DCC CHAT, donde el protocolo chat se reemplaza por wboard : .DCC CHAT wboard ipport

Una vez establecida la conexión, los dos clientes intercambian mensajes terminados en CRLF . Los mensajes que comienzan (y opcionalmente terminan) con ASCII 001 se interpretan como comandos especiales; el comando ACTION representa un emoticono, mientras que otros hacen que se dibujen líneas en la pizarra del usuario o permiten que los dos clientes negocien un conjunto de funciones.

DCC ENVIAR

El servicio SEND permite a los usuarios enviarse archivos entre sí. La especificación original del protocolo de enlace no permitía al receptor conocer el tamaño total del archivo ni reanudar una transferencia. Esto ha llevado a que los clientes introduzcan sus propias extensiones al protocolo de enlace, muchas de las cuales cuentan con un amplio soporte.

El protocolo de enlace original consistía en que el remitente enviaba el siguiente CTCP al receptor: .DCC SEND filenameipport

Al igual que con DCC CHAT, ip y puerto son la dirección IP y el puerto donde la máquina remitente estará escuchando una conexión entrante. Algunos clientes encierran los nombres de archivo con espacios entre comillas dobles. Es práctica común agregar el tamaño del archivo como último argumento: .DCC SEND filenameipportfilesize

En este punto, la especificación original hacía que el receptor se conectara a la dirección y puerto dados y esperara datos, o ignorara la solicitud, pero para los clientes que admiten la extensión DCC RESUME, una tercera alternativa es pedirle al remitente que omita parte del archivo enviando la respuesta CTCP: .DCC RESUME filenameportposition

Si el cliente emisor admite DCC RESUME, responderá con , y el receptor podrá conectarse a la dirección y puerto proporcionados y escuchar los datos para agregarlos a un archivo ya existente.DCC ACCEPT filenameportposition

Los datos se envían al cliente en bloques, y el cliente debe confirmar cada recepción enviando el número total de bytes recibidos en forma de un entero de orden de bytes de red de 32 bits . Esto ralentiza las conexiones y resulta redundante debido a TCP . La extensión de envío anticipado alivia este problema en cierta medida al no esperar las confirmaciones, pero dado que el receptor aún debe enviarlas por cada bloque que recibe, en caso de que el remitente las espere, el problema no se resuelve por completo.

Otra extensión, TDCC o turbo DCC, elimina las confirmaciones, pero requiere un protocolo de enlace ligeramente modificado y no cuenta con un amplio soporte. Las versiones anteriores de TDCC reemplazaban la palabra SEND en el protocolo de enlace con TSEND; las versiones posteriores usan la palabra SEND pero agregan una T después del protocolo de enlace, lo que hace que esta versión de TSEND sea compatible con otros clientes (siempre que puedan analizar el protocolo de enlace modificado).

Explotación de DCC SEND

El "exploit de envío de DCC" puede referirse a dos errores: un error de desbordamiento de búfer variante en mIRC activado por nombres de archivo de más de 14 caracteres, [ 6 ] y un error de validación de entrada en algunos enrutadores fabricados por Netgear , D-Link y Linksys , activado por el uso del puerto 0. [ 7 ] [ 8 ] El exploit del enrutador, en particular, puede activarse cuando la frase ' DCC SEND ' seguida de al menos 6 caracteres sin espacios ni saltos de línea aparece en cualquier parte de un flujo TCP en el puerto 6667, no solo cuando se ha realizado una solicitud DCC SEND real. En la década de 2000 era posible combinar múltiples exploits en una sola cadena, DCC SEND startkeylogger 0 0 0 , que si se publicaba en un canal público podía provocar la desconexión de varios usuarios (ya sea bloqueando clientes IRC, bloqueando enrutadores o activando configuraciones predeterminadas demasiado estrictas en el software antivirus).

DCC XMIT

El servicio XMIT es una versión modificada de DCC SEND que permite reanudar la transferencia de archivos y reduce el tráfico innecesario generado por los paquetes ACK largos. XMIT no cuenta con un amplio soporte.

El protocolo de enlace XMIT difiere ligeramente del protocolo de enlace SEND. El remitente envía un CTCP ofreciendo un archivo al receptor:DCC XMIT protocolipport[ name[ size[ MIME-type]]]

Los corchetes aquí encierran partes opcionales. protocol es el protocolo que se utilizará para la transferencia; actualmente solo se define clear . A diferencia del DCC SEND estándar, ip puede estar en las formas adicionales de notación estándar con puntos para IPv4, o en notación hexadecimal o mixta para IPv6. Para dejar un parámetro inicial vacío, pero proporcionar uno posterior, el anterior se puede especificar como - . Si el receptor no implementa el protocolo utilizado, enviará una respuesta CTCP con el formato: .ERRMSG DCC CHAT protocol unavailable

Aquí se utiliza CHAT para mantener la compatibilidad con los mensajes de error enviados por el CHAT DCC extendido. Si el receptor rechaza la transferencia, envía la siguiente respuesta CTCP: .ERRMSG DCC CHAT protocol declined

Los demás errores se notifican de la misma manera. Si el receptor está dispuesto y es capaz de recibir el archivo, se conectará a la dirección y el puerto indicados. Lo que ocurra después dependerá del protocolo utilizado.

En el caso del protocolo claro , el servidor XMIT, al recibir una conexión, enviará un byte de 32 bits en orden de bytes de red , que representa la hora de modificación del archivo. Presumiblemente, basándose en la hora de modificación del archivo local, el cliente enviará otro byte en orden de bytes de red , un desplazamiento al que el servidor debe dirigirse al enviar el archivo. Este desplazamiento debe establecerse en cero si se desea el archivo completo, o en el tamaño del archivo local si el cliente desea reanudar una descarga anterior.time tlong

Si bien es más rápido que SEND, XMIT presenta una limitación similar: es imposible determinar el tamaño del archivo a menos que se especifique en la negociación CTCP o se conozca de antemano. Además, debido al desplazamiento de 32 bits, no es posible reanudar la descarga de un archivo que supere los dos gigabytes.

DCC pasivo

En una conexión DCC normal, el iniciador actúa como servidor y el destino como cliente . Debido a la amplia implementación de cortafuegos y a la reducción de la transparencia de extremo a extremo por culpa de NAT , es posible que el iniciador no pueda actuar como servidor. Se han ideado diversas maneras de solicitar al destino que actúe como servidor:

Servidor DCC

Esta extensión a las funciones normales de DCC SEND y CHAT fue introducida por el cliente IRC mIRC . DCC Server cuenta con soporte moderado, pero no viene instalado de forma estándar en todos los clientes (véase Comparación de clientes de Internet Relay Chat ).

Permite iniciar una conexión DCC mediante la dirección IP, sin necesidad de un servidor IRC. Esto se logra cuando el cliente receptor actúa como servidor (de ahí su nombre) y espera (normalmente en el puerto 59) una señal de confirmación del remitente.

Para un CHAT, el iniciador envía . El destinatario responde con , , y el resto procede según el protocolo estándar DCC CHAT.1000 initiator nick1000 target nick

Para un SEND, el iniciador envía . El destinatario responde con , donde la posición de reanudación es el desplazamiento en el archivo desde donde comenzar. A partir de aquí, la transferencia procede como un DCC SEND normal.1200 initiator nickfilesizefilename1210 target nickresume position

DCC Server también admite servidores de archivos de estilo mIRC y DCC GET.

Relé DCC

El reenvío DCC es un script para reenviar una transferencia DCC a otro usuario. [ 9 ] El usuario configurará el script de reenvío DCC con un usuario, un apodo y un servidor en un cuadro de diálogo. Una vez configurados el apodo y el servidor, el usuario podrá solicitar un archivo a un bot XDCC , y la transferencia del archivo se reenviará al otro usuario. Este método puede ser utilizado por los canales XDCC para alimentar sus bots XDCC desde otros canales XDCC.

RDCC

El servidor DCC no permite especificar el puerto a utilizar, por lo que este debe negociarse manualmente, lo cual no siempre es posible, ya que una de las partes podría no ser humana. RDCC es un mecanismo de enlace para el servidor DCC que, además del puerto, proporciona la dirección IP del servidor, la cual el cliente podría no encontrar de otra manera debido al enmascaramiento de host. Su compatibilidad es limitada.

El iniciador solicita el puerto en el que el objetivo está escuchando enviando la consulta CTCP, donde la función es c para chat, s para enviar o f para servidor de archivos.RDCC functioncomment

El destinatario puede entonces responder mediante CTCP con , donde ip y puerto tienen el mismo significado que para DCC SEND y CHAT normales. Después de esto, el iniciador se conecta a la ip y puerto , y se produce un intercambio de claves con el servidor DCC.RDCC 0 ipport

DCC INVERSA

A diferencia de DCC Server, donde el protocolo de enlace se realiza mediante una conexión IP directa, DCC REVERSE utiliza un protocolo de enlace CTCP estándar, similar al que usa DCC SEND. Este protocolo no está ampliamente implementado. El remitente ofrece un archivo al receptor enviando el mensaje CTCP: . La clave es una cadena de caracteres ASCII de entre 1 y 50 caracteres , en el rango 33-126, y actúa como identificador de la transferencia.DCC REVERSE filenamefilesizekey

Si el receptor acepta, envía la respuesta CTCP,DCC REVERSE keystartipport

Aquí, start es la posición en el archivo desde donde comenzar a enviar, ip es la dirección IP del receptor en notación estándar con puntos para IPv4 o notación hexadecimal para IPv6 . El remitente se conecta a la dirección IP y al puerto indicados por el receptor, y a continuación se realiza un DCC SEND normal. Tanto el remitente como el receptor pueden cancelar el handshake enviando la respuesta CTCP .DCC REJECT REVERSE key

DCC RSEND

Esta es la alternativa del cliente KVIrc a DCC REVERSE. El remitente ofrece un archivo enviando el CTCP: . El receptor puede entonces aceptarlo respondiendo con CTCP con , , y el remitente se conecta al receptor y envía como durante un DCC SEND normal.DCC RSEND filenamefilesizeDCC RECV filenameipportstart

DCC inverso/cortafuegos

Este mecanismo DCC pasivo es compatible con al menos mIRC , Visual IRC , HexChat , KVIrc, DMDirc , Klient , Konversation y PhibianIRC . El remitente ofrece un archivo enviando el mensaje CTCP, . ip es la dirección IP del remitente en orden de bytes de red, expresada como un solo entero (como en DCC estándar). El número 0 se envía en lugar de un puerto válido, señalando que se trata de una solicitud DCC inversa. token es un entero único; si se está utilizando TSEND (por un cliente que lo admite), la letra T se agrega al token, lo que le hace saber al receptor que no necesita enviar confirmaciones.DCC SEND filenameip 0 filesizetoken

El receptor puede aceptar el archivo abriendo un socket de escucha y respondiendo con el mensaje CTCP . Este mensaje es idéntico al mensaje DCC inverso original, excepto que la IP y el puerto identifican el socket donde el receptor está escuchando. El token es el mismo que en la solicitud original, lo que permite al remitente saber qué solicitud se está aceptando. (Dado que este mensaje sigue el mismo formato que una solicitud de envío DCC normal, algunos servidores que filtran las solicitudes DCC pueden requerir que el remitente agregue al receptor a su lista de "permisos DCC").DCC SEND filenameipportfilesizetoken

El remitente se conecta entonces al socket del receptor, envía el contenido del archivo y espera a que el receptor cierre el socket cuando el archivo haya terminado.

Cuando se utiliza la extensión RESUME del protocolo SEND, la secuencia de comandos se convierte en (donde >> indica un mensaje saliente en el lado iniciador y << una respuesta de su par):

>> DCC SEND filenameip 0 filesizetoken << DCC RESUME filename 0 positiontoken >> DCC ACCEPT filename 0 positiontoken << DCC SEND filenamepeer-ipportfilesizetoken

Después de esto, el protocolo continúa con normalidad (es decir, el remitente se conecta al socket del receptor).

Servidores de archivos (FSERV)

Un servidor de archivos DCC permite al usuario explorar, leer y descargar archivos ubicados en un servidor DCC.

Normalmente, esto se implementa mediante una sesión de chat DCC (que muestra al usuario un indicador de comandos) o comandos CTCP especiales para solicitar un archivo. Los archivos se envían a través de DCC SEND o DCC XMIT. Existen numerosas implementaciones de servidores de archivos DCC, entre ellas el comando FSERV del popular cliente mIRC .

Véase también

Referencias

  1. ↑ Mikulėnas, Mantas; Oakley, Daniel (2018-01-09). Internet Relay Chat: Protocolo de cliente a cliente (CTCP) (Informe). Grupo de trabajo de ingeniería de Internet.
  2. ↑ Piccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (1 de mayo de 2005). «Redes IRC y seguridad». Protección de aplicaciones de mensajería instantánea y P2P para la empresa (1.ª ed.). Syngress. pág. 386. ISBN   1-59749-017-2Los autores del paquete de software ircII fueron los pioneros en la transferencia de archivos a través de IRC .
  3. ↑ Consulte los archivos 'NOTAS' y 'source/ctcp.c' incluidos con ircii-2.1.4e.tar.gz
  4. ↑ Consulte los archivos 'UPDATES' y 'source/dcc.c' incluidos con ircii-2.1.4e.tar.gz
  5. ↑ "Ayuda de mIRC" . www.mirc.com . Consultado el 24 de julio de 2023 .
  6. ↑ "Información sobre exploits de SecurityFocus" .
  7. ↑ "CVE - CVE-2006-1068" . cve.mitre.org .
  8. ↑ "CVE - CVE-2006-1067" . cve.mitre.org .
  9. ↑ https://web.archive.org/web/20090804013445/http://www.hawkee.com/snippet/4739/
  • Detalles del CTCP