Resumen

  • Un TLS o SASL satisfactorio obligaba a XMPP a sustituir el flujo XML, sin el cierre normal </stream> y sin terminar la conexión TCP subyacente.
  • Cada nueva generación recibía encabezados, identificador y funciones propios; tener TCP abierto, cifrado, autenticación, recurso vinculado y una estrofa aceptada nunca fueron la misma constatación.

Un protocolo que desconfiaba de la continuidad aparente

La palabra <success/> parece prometer continuación. En el intercambio SASL de XMPP hacía algo más preciso: confirmaba el resultado y convertía en viejo el flujo que acababa de transportarlo. El cliente tenía que iniciar otro sobre la conexión TCP existente. El servidor respondía con un identificador nuevo y con las funciones que ahora correspondían a una entidad autenticada.

TLS seguía la misma forma. Tras proceed, la negociación criptográfica ocupaba la conexión y no podía mezclarse con más XML. Si terminaba bien, el iniciador abría un nuevo flujo dentro del canal cifrado. No enviaba primero la etiqueta de cierre del anterior. La especificación consideraba que el éxito lo había reemplazado.

Esa decisión evitaba dos extremos. No era necesario pagar una reconexión TCP en cada etapa. Tampoco se permitía que las afirmaciones del flujo previo atravesaran la frontera como si la nueva protección las hubiese certificado retroactivamente.

El socket sobrevivía; la generación XML no

RFC 6120 explica que un flujo XMPP es un objeto de aplicación y, estrictamente, unidireccional. TCP es bidireccional y puede sostener los flujos en ambos sentidos. Por eso sus ciclos de vida no coinciden por definición.

Cuando una función exige reinicio, ambas partes sustituyen el flujo precedente, omiten su cierre ordinario y reutilizan TCP. El iniciador manda un encabezado inicial nuevo. El receptor crea otro ID de flujo antes de contestar. La conexión puede estar ahora cifrada o haber adquirido una capa de seguridad SASL; el nuevo flujo nace dentro de ese estado.

No es recuperación de mensajes. Ninguna regla de reinicio demuestra que las estrofas anteriores llegaron, que deban repetirse o que la aplicación remota actuó. Tampoco es una nueva conexión de transporte. Es un cambio de generación dentro de una continuidad inferior.

Una implementación puede mantener un único descriptor de socket y, a la vez, atravesar tres contextos: antes de TLS, después de TLS y después de SASL. Tratar esos contextos como una sola sesión borra qué datos se aprendieron bajo qué garantías.

La lista de funciones hablaba en presente

Al responder a un encabezado, el servidor anunciaba «stream features». Algunas eran obligatorias para seguir; otras, voluntarias. Mientras quedase una obligatoria, la negociación no había terminado y las estrofas ordinarias todavía no estaban liberadas. Una lista vacía o compuesta solo por opciones voluntarias señalaba el final de esa fase.

La oferta dependía de la etapa. XMPP colocaba TCP primero, TLS después, SASL a continuación y por último el intercambio XMPP ya negociado. Los mecanismos SASL podían variar según hubiera TLS. La vinculación de recurso solo se mostraba al cliente después de autenticarlo.

Por eso el servidor debía volver a anunciar funciones al recibir cada nuevo encabezado. No era redundancia. La nueva lista evitaba que una capacidad observada antes de la protección o antes de la identidad se convirtiera en derecho permanente.

Tampoco una ausencia era universal. Una función podía no ser pertinente todavía o haber dejado de serlo. Además, RFC 7590 advierte que un atacante puede quitar la oferta STARTTLS o la indicación required. Lo visto en un trayecto es evidencia del trayecto, no un inventario definitivo del servidor.

TLS no debía legitimar lo aprendido a oscuras

La regla más reveladora aparece después de una negociación TLS satisfactoria. Las dos entidades deben descartar la información recibida de forma insegura por encima de TCP antes de que TLS entrase en vigor. Entre los ejemplos están el from, el ID de flujo y las funciones anunciadas.

El riesgo es sutil. Si un intermediario modifica una dirección o una oferta antes del cifrado y el sistema la conserva después, la interfaz segura termina dando prestigio a un dato que nunca recibió protegido. Reiniciar obliga a reexpresar las condiciones relevantes dentro del canal nuevo.

Sin embargo, cifrado y autenticación del par siguen siendo dimensiones distintas. RFC 7590 endureció las prácticas TLS para XMPP, exige que los clientes autentiquen a los servidores y que los servidores autentiquen a los clientes, y prefiere con fuerza la autenticación entre servidores. Aun así, distingue conexiones cifradas pero no autenticadas como casos de menor fuerza.

El operador necesita saber qué nombre se verificó, por qué mecanismo, contra qué credencial y con qué resultado. La aparición de un flujo post-TLS prueba una transición del protocolo; no completa por sí sola el expediente de identidad.

SASL daba un resultado, no una licencia total

RFC 4422 permite que protocolos orientados a conexión reutilicen mecanismos de autenticación. Separa la identidad autenticadora de la identidad autorizada y contempla que ciertos mecanismos añadan una capa de integridad o confidencialidad. Esa capa no existe por el mero uso del nombre SASL.

XMPP encaja la negociación en XML y exige reiniciar tras ella. El <success/> indica que el mecanismo acabó favorablemente; no dice que el cliente haya completado todas las obligaciones de XMPP ni que pueda actuar sobre cualquier destino.

Después aparece la vinculación de recurso. El servidor une una parte de recurso a la cuenta autenticada para formar la dirección completa del cliente y distinguirla de otras conexiones de la misma cuenta. Antes de ese paso, si el cliente envía una estrofa a un tercero, el servidor no debe procesarla y debe cerrar el flujo por falta de autorización.

Así, un único TCP puede estar cifrado y tener SASL exitoso mientras el flujo todavía no admite tráfico normal. «Conectado», «protegido», «autenticado» y «listo» son estados diferentes, no sinónimos de interfaz.

La excepción final explicaba la regla

Tras la vinculación de recurso, RFC 6120 prohíbe reiniciar el flujo. El mandato negativo es importante: XMPP no aplicó el reinicio mecánicamente a cada éxito. Lo usó cuando la negociación cambiaba el contexto de seguridad o identidad que daba significado a lo ya recibido.

La vinculación ocurre dentro del flujo post-SASL. Cambia el direccionamiento y completa una condición obligatoria, pero no invalida los encabezados ni las funciones aprendidas en ese mismo contexto autenticado. Provocar otro reinicio sería inventar una frontera que la especificación no requiere.

Este detalle ayuda a diseñar pruebas. Un cliente que no reinicia tras TLS está mal. Uno que no reinicia tras SASL también. Uno que reinicia después de vincular puede estar igualmente mal. Las transiciones correctas dependen de la semántica, no del reflejo de «éxito igual a reinicio».

También protege la lectura de registros. El nuevo ID de flujo es un correlador de generación, no una identidad humana. El recurso vinculado identifica una instancia conectada, no confirma entrega. La aceptación local de una estrofa no demuestra el efecto en el destino.

De la primera norma a un modelo de estados explícito

RFC 3920, de octubre de 2004, ya describía flujos nuevos después de TLS y SASL y situaba las capas en el orden TCP, TLS, SASL y XMPP. Consideraba terminado el flujo original al completarse esas negociaciones, sin necesitar la etiqueta de cierre.

RFC 6120 lo reemplazó en 2011 y articuló una regla general de sustitución: conservar la conexión, abrir un encabezado nuevo, crear otro ID y reenviar las funciones actualizadas. La arquitectura quedó menos dependiente de ejemplos aislados y más claramente expresada como negociación por etapas.

RFC 7590 actualizó en 2015 las recomendaciones TLS ante ataques y prácticas más modernas. Ese endurecimiento confirma una frontera editorial importante: obedecer la secuencia no garantiza que las elecciones criptográficas o de validación sean suficientes. La coreografía y la calidad de la seguridad deben auditarse por separado.

El aporte histórico de XMPP no fue convertir cada conexión en una identidad. Fue mostrar que una capa inferior puede continuar mientras la superior renuncia a su memoria. Mantener TCP ahorra trabajo; no conservar ciegamente el contexto evita que una verdad provisional se vuelva autoridad permanente.

Fuentes