Resumen

  • FEP transportaba un datagrama IP completo en el cuerpo HTTP; un equipo colaborador dentro del cortafuegos lo decodificaba y lo insertaba en su pila de protocolos.
  • El paso de la conexión HTTP solo probaba la admisión del portador. No demostraba permiso para las direcciones, puertos, aplicación, usuario o efecto del paquete oculto.

La regla veía el exterior

El documento partía del choque entre la innovación en los extremos y el control en el camino. Una aplicación nueva podía funcionar entre dos hosts y aun así quedar detenida porque el cortafuegos corporativo no reconocía su tráfico. RFC 3093 llevó una respuesta hasta la caricatura: si HTTP solía pasar, cualquier datagrama podía vestirse de HTTP.

El recorrido era preciso. El host exterior entregaba el datagrama a FEP. El programa lo colocaba en un mensaje HTTP y lo enviaba por el camino ordinario. Un programa dentro lo extraía, reconstruía y entregaba a la pila IP protegida, como si el cortafuegos no existiera.

Pero lo observado seguía siendo una conexión exterior. El paquete interior conservaba otro origen, destino, transporte e intención. La aprobación de la envoltura no podía heredarse sin una regla específica para la carga.

El colaborador interno adquiría autoridad

RFC 3093 decía conservar la seguridad porque necesitaba la cooperación de un host interior. Su razonamiento suponía que el cortafuegos combatía riesgos externos e ignoraba los internos. Esa era la premisa del texto, no una garantía. El proceso con permiso para decodificar e inyectar datagramas arbitrarios se convertía en un nuevo punto de control.

El administrador del cortafuegos elegía qué conexión exterior pasaba. El operador del host habilitaba FEP y el privilegio de reinyección. El usuario escogía la aplicación. El software interpretaba los bytes. Ninguno de esos hechos aislados demostraba autorización corporativa para el conjunto.

Por lo mismo, un registro de HTTP aceptado no describía el flujo escondido. La recepción en el túnel no probaba la reinyección. La reinyección no probaba que una socket o aplicación aceptara el paquete, y menos aún un resultado fuera del equipo.

Los encabezados legibles eran copias

El datagrama completo iba en el cuerpo HTTP. Además, el protocolo copiaba campos TCP y opcionalmente IP a encabezados de lectura humana: números de puerto en decimal, mayúsculas para urgencia, saltos restantes narrados en palabras y fuentes aparentes como nombres de dominio.

El propio RFC decía que esas copias servían solo para legibilidad porque el datagrama ya estaba incluido. Un valor visible no autenticaba el campo real. Las representaciones podían discrepar. Un implementador necesitaba decidir qué entrada gobernaba la reconstrucción, validar límites y aplicar política antes de insertar nada.

Enviar cada paquete como GET o respuesta a GET también imitaba una forma admitida. No convertía el datagrama en una petición Web normal. La sintaxis era el disfraz que el intermediario reconocía. El ejercicio mostraba que reconocer protocolo y reconocer intención eran problemas distintos.

La sátira conservó una pregunta operacional

La fecha, los campos absurdos y una sección de seguridad que niega cualquier consideración sitúan el documento como provocación Informational. No es evidencia de una implantación segura, ni de implantación alguna. Tampoco hace falta asegurar qué pensaban los autores: el mecanismo publicado basta para demostrar cómo una regla amplia puede transportar más de lo que su nombre sugiere.

RFC 2775 examinó la pérdida de transparencia; RFC 2979 los requisitos de comportamiento del cortafuegos; RFC 2663, RFC 3027 y RFC 3234 las consecuencias de NAT y middleboxes. SOCKS5 exigía negociación con un gateway y podía usar autenticación. Son capas adyacentes, no pruebas de que FEP funcionara.

La conclusión es limitada. Un cortafuegos puede admitir correctamente HTTP y no haber evaluado el protocolo interior. Probar control exige identificar el extremo del túnel, autenticarlo, limitar el paquete decodificado, registrar la reinyección y observar la aplicación. El éxito de una capa no llena los recibos que faltan en las demás.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3093
  2. https://www.rfc-editor.org/rfc/rfc3093.html
  3. https://www.rfc-editor.org/rfc/rfc3093.txt
  4. https://datatracker.ietf.org/doc/rfc3093/
  5. https://www.rfc-editor.org/errata/rfc3093
  6. https://www.rfc-editor.org/rfc/rfc2775.html
  7. https://www.rfc-editor.org/rfc/rfc2979.html
  8. https://www.rfc-editor.org/rfc/rfc3234.html
  9. https://www.rfc-editor.org/rfc/rfc2663.html
  10. https://www.rfc-editor.org/rfc/rfc3027.html
  11. https://www.rfc-editor.org/rfc/rfc1928.html
  12. https://www.rfc-editor.org/rfc/rfc2616.html
  13. https://www.rfc-editor.org/rfc/rfc793.html
  14. https://www.rfc-editor.org/rfc/rfc791.html
  15. https://www.rfc-editor.org/rfc/rfc2119.html