Resumen

  • RFC 742 definió en 1977 que una línea compuesta solo por CRLF solicitaba la lista de todas las personas conectadas, con nombre, ubicación del terminal y otros datos humanos útiles.
  • RFC 1288 conservó la pregunta de una línea, pero exigió responder o rechazar activamente la lista general y el reenvío, y recomendó que el administrador eligiera cada elemento divulgado.
  • La asignación del puerto 79 coordinó dónde preguntar. No autenticó al sujeto, no garantizó la veracidad de la respuesta, no creó derecho a conocerla y no volvió seguro el texto que un cliente mostraba.

La ausencia de texto era una orden completa

El procedimiento de RFC 742, fechado el 30 de diciembre de 1977, cabía en pocas acciones: conectar al socket 117 octal, 79 decimal; enviar una línea terminada en CRLF; recibir texto variable y dejar que el servidor cerrara al finalizar.

Cuando la línea era nula, la respuesta por defecto debía enumerar a todas las personas que usaban el sistema. El documento pedía, como mínimo, nombres completos y ubicaciones físicas de los terminales cuando pudieran determinarse. Añadir el nombre del trabajo y los minutos de inactividad era razonable y útil.

Una consulta con usuario pedía un informe individual, estuviera o no conectado. Podía incluir el último cierre de sesión y un mensaje corto en un archivo especial: el plan. Esa pieza permitía dejar un horario, una ausencia o instrucciones de contacto para quien preguntara desde otra máquina.

El origen ayuda a entender la expectativa. RFC 742 mencionaba SAIL, SRI y sistemas ITS. Atribuía a FINGER, escrito por Les Earnest en SAIL, la inspiración de NAME en ITS, y a Earl Killian y Brian Harvey la implementación del protocolo. En una comunidad de investigación pequeña, conocer la presencia de colegas parecía parte de la coordinación cotidiana.

Sin embargo, la línea vacía no expresaba propósito ni relación. La pregunta predeterminada no era por una persona: exigía a todas. Cuando creció la red, el mismo gesto amistoso quedó disponible para una audiencia que el sujeto ya no conocía.

Una salida para humanos podía crecer sin esquema

Finger no fijó formato porque esperaba un lector, no otro programa. Cada sistema podía presentar lo que sabía. La ventaja era adaptabilidad; el coste era que una respuesta podía acumular nombres, terminales, oficinas, teléfonos, shell, directorio, correo y texto personal sin un límite semántico común.

/W pedía mayor verbosidad. En el documento inicial se llamaba Whois switch. RFC 1288 corrigió su ubicación al principio de la consulta; el último servidor debía usarlo para un detalle superior o ignorarlo. No había una autenticación adicional que justificara recibir más.

También podían ampliarse los nombres. El login era obligatorio, pero apellidos y nombres completos podían aceptarse. Si una palabra correspondía a varias personas, el servidor podía devolver candidatos. La ayuda para quien no recordaba la cuenta exacta servía igualmente para enumerar usuarios por aproximación.

La legibilidad no hacía comparables los resultados. “Inactivo” podía contar desde la última tecla o desde la actividad del proceso. Una ausencia podía significar que nadie estaba conectado, que el servidor no sabía o que una política ocultaba el dato. Cada respuesta era la vista local de quien contestaba.

El avance decisivo fue permitir un no visible

RFC 1196, publicado en diciembre de 1990, tomó como base el comportamiento BSD predominante. Quiso aclarar sin invalidar numerosos sistemas y subrayó que devolver información sobre usuarios era, por su propia finalidad, una cuestión sensible.

RFC 1288 llegó un año después y corrigió /W, los espacios de la gramática y el cierre. El intercambio siguió siendo TCP 79, ASCII, una línea CRLF, una respuesta y fin. La novedad profunda fue convertir la política en resultado observable.

Ante {C}, la consulta vacía, el RUIP tenía que contestar o negar activamente. Si contestaba, al menos entregaba nombres completos. El administrador debía poder decidir si agregaba ubicación del terminal o la oficina, teléfono, trabajo e inactividad. Si desactivaba la lista, podía decirlo sin fingir que no había usuarios.

Una lista vacía parece una observación: cero personas. Un rechazo describe otra cosa: el sitio no publica la población. Separarlas evita que una decisión de privacidad se presente como estado operacional.

La norma recomendó además controlar los átomos de información. Un administrador podía incluir teléfonos y tiempos de entrada; otro, solo oficina y contacto profesional; un tercero, el nombre mínimo. Compartir protocolo dejó de significar compartir un paquete universal de datos personales.

El reenvío cambiaba quién alcanzaba a quién

Una consulta Q2 admitía una cadena de @hostname. El primer servidor abría otra conexión Finger, enviaba el resto de la pregunta y devolvía lo recibido. La gramática no imponía un límite arbitrario al número de saltos.

RFC 1288 obligó a prestar el reenvío o rechazarlo de forma explícita. Recomendó negarlo por defecto, sobre todo en gateways. Una máquina visible desde fuera podía consultar en nombre del visitante a otra interna, abriendo un camino a través del perímetro.

El intermediario no autenticaba al visitante ni convertía el dato interior en información pública. Solo prestaba su alcance. Que todos los saltos hablaran Finger correctamente no demostraba que conservaran la autoridad para hacer la pregunta.

Por eso una auditoría no puede detenerse en los hosts con puerto 79 directamente abierto. Debe probar Q2, identificar al respondedor final, revisar cómo se expresa el rechazo y unir los registros de cada tramo.

El autor del plan no controlaba toda la distribución

El plan ofrecía voz directa al usuario. Podía contar dónde estaría o cómo contactarlo. Pero escribir una nota no significaba conocer todos los orígenes capaces de descargarla. Autoría y alcance eran decisiones distintas.

RFC 1288 advirtió que devolver un archivo modificable por el usuario equivalía potencialmente a distribuir cualquier información sobre el sistema. Una persona podía revelar sin querer, otra podía engañar y la implementación podía fallar al ubicar o leer el archivo.

Algunos servicios permitían ejecutar un programa del usuario al recibir la consulta. La lectura se convertía en ejecución remota activada por una línea. La opción debía poder apagarse y nunca comprometer la seguridad del sistema.

Hay tres autoridades: el usuario escribe; el operador define qué sale del host; el cliente decide cómo lo presenta. El permiso de una no sustituye a las otras dos.

El texto humano seguía siendo entrada hostil

RFC 1288 aconsejó filtrar por defecto todo carácter no imprimible y conservar ASCII visible, tabulaciones y CRLF. Una secuencia de escape podía cambiar nombres de ventanas X o producir efectos confusos en el terminal del lector.

El envío tenía su propio choque. RFC 742 ya advertía que un cliente Telnet genérico podía insertar negociación IAC y contaminar la línea que Finger interpretaba. Transportar caracteres no convierte dos protocolos de texto en intercambiables.

“Hecho para humanos” designaba al lector final, no una garantía de inocuidad. El emisor debía construir la pregunta exacta; el receptor debía separar los datos remotos de las órdenes para su interfaz.

Un daemon seguro todavía podía revelar demasiado

RFC 1288 recordó el gusano Morris al pedir pruebas de penetración para Finger. Colocó el servicio junto a Telnet, FTP y SMTP en el perímetro de un host. El tamaño pequeño no eliminaba la exposición del parser a entradas malformadas.

La seguridad informativa era otra dimensión. El documento cita una implementación que daba último login, última lectura del correo, mensajes pendientes e incluso el remitente del último no leído. Sin explotar memoria, alguien podía seguir conversaciones y atención.

Reducir campos tampoco demostraba que el código fuera sólido. Entradas malformadas, reenvío, programas y caracteres de control necesitaban pruebas separadas. Minimizar datos y robustecer el proceso se complementaban, no se reemplazaban.

Registrar consultas ayudaba a observar enumeración, nombres repetidos, /W y Q2. Pero el log también almacenaba quién mostraba interés por quién. Requería propósito, acceso limitado y fecha de borrado.

IANA conservó el domicilio, no concedió acceso

El registro de servicios y puertos de IANA mantiene finger en el puerto 79 para TCP y UDP. RFC 1288 define el servicio TCP. La asignación coordina un lugar conocido.

No prueba que un host lo ejecute hoy, que la respuesta sea exacta o que el visitante merezca un campo. El número es domicilio si existe el servicio; el operador decide abrir y revelar, el usuario controla solo el material que se le permite aportar, y el receptor decide el efecto del texto.

Finger mostraba una vista momentánea de sesiones y, a veces, una auto-descripción. No era una afirmación firmada de identidad ni un expediente administrativo con historial de cambios.

Sobrevivió la pregunta cuando perdió su autoridad predeterminada

No basta decir que una Internet ingenua aprendió seguridad. El documento de 1977 ya conocía formatos diversos y la contaminación Telnet. Las normas posteriores no eliminaron el valor de localizar personas; hicieron visibles las decisiones que ese valor exigía.

La consulta vacía permaneció, pero podía rechazarse. El perfil permaneció, pero con campos configurables. El reenvío permaneció, pero debía negarse por defecto. El plan permaneció, sin convertir la autoría en distribución ilimitada. La salida libre permaneció, con filtrado del cliente.

Finger no fabricó privacidad automática. Identificó dónde debía gobernarse. El puerto 79 contestó dónde preguntar; el operador decidió si divulgar; el cliente decidió cómo mostrar. La línea compartida no otorgó a ninguno el poder de hablar por los demás.

Fuentes y límites de evidencia

Las fuentes establecen historia, sintaxis, recomendaciones de seguridad y registro. No miden despliegue actual, frecuencia de ataques ni política de un sitio. La entrada de IANA no se usa como censo, ni los campos de ejemplo como descripción de toda implementación histórica.