Resumen

  • CGI/1.1 describió una entrega común de solicitud y respuesta entre un servidor HTTP y un script, aunque algunos detalles siguieran definidos por el sistema o por cada implementación.
  • RFC 3875 situó TLS entre cliente y servidor: el servidor se autenticaba ante el cliente, mientras que el script no recibía una prueba incorporada de quién lo invocó ni de la integridad del mensaje CGI.

La conexión es segura. La aplicación no tiene por qué estar al otro lado de ella.

Ese es el límite discreto de RFC 3875, la especificación Common Gateway Interface (CGI) versión 1.1 de 2004. Un navegador puede establecer TLS con un servidor web. Después, el servidor puede entregar los datos de la solicitud a un programa CGI. Pero la relación de seguridad que describe el RFC no atraviesa intacta ese segundo paso. El servidor es el par de red; el script es un proceso de aplicación situado detrás.

CGI ya prestaba un servicio útil mucho antes de que apareciera RFC 3875. Un servidor HTTP podía funcionar como pasarela hacia una base de datos u otro sistema de información existente, mientras un script generaba una respuesta a partir de la solicitud. La página histórica del W3C describe CGI como un acuerdo entre implementadores de servidores para integrar scripts y programas de pasarela. Registra un intento de actualizar CGI 1.1 en 1995 y la reactivación, en noviembre de 1997, de un esfuerzo para convertir una interfaz de facto en un RFC informativo. El texto final se publicó en octubre de 2004 dentro del flujo independiente.

El intervalo importa menos como curiosidad del proceso de estándares que como pista sobre lo que el documento intentaba fijar. CGI ya era una convención práctica. RFC 3875 no inventó las aplicaciones web dinámicas: escribió un contrato portable para una solicitud que debía cruzar desde un servidor conectado a la red hasta un programa de aplicación.

El contrato nombra «metavariables» como REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, PATH_INFO y REMOTE_ADDR. Define cómo devuelve un script las cabeceras y el cuerpo, incluidas las respuestas de documento y de redirección. Así, programas ejecutados por servidores distintos comparten vocabulario. También reparte responsabilidades: el servidor gestiona la conexión del cliente, la transferencia de datos y el protocolo de red; el script se ocupa de la aplicación, como el acceso a datos y el procesamiento de documentos.

La división no transfiere las obligaciones del servidor. RFC 3875 dice que, aunque un script incumpla la especificación, el servidor sigue siendo responsable ante el cliente de respetar el protocolo de red. También exige que un servidor que aplica autenticación no ejecute el script hasta que la solicitud haya superado los controles de acceso definidos. El servidor no es simplemente un conducto que pueda culpar a su proceso hijo de una respuesta incorrecta o de un control omitido.

La sección 9.4 estrecha después el límite de confianza. Para una conexión TLS, el modelo de seguridad se aplica entre cliente y servidor, no entre cliente y script. El servidor es quien se autentica ante el cliente. La especificación no ofrece al script un mecanismo para autenticar al servidor que lo invocó y no garantiza la integridad de los mensajes CGI de solicitud y respuesta.

Eso no significa que el script deba considerarse hostil ni que el operador no pueda proteger el proceso local. El servidor puede usar permisos del sistema operativo, un canal privado u otros controles. El punto es más acotado: TLS en el borde HTTP no autentica por sí solo al script posterior como si fuera el mismo par de red. Si el script recibe HTTPS=on o un nombre de usuario en su entorno, recibe valores; la interfaz CGI no aporta una prueba criptográfica que los vincule a una sesión de cliente autenticada.

La arquitectura era más amplia que un solo modelo de proceso. RFC 3875 describe como implementación más común un proceso hijo bajo el usuario y grupo del servidor, pero también reconoce scripts enlazados dentro del servidor. Distingue entre comportamiento «definido por el sistema» y «definido por la implementación». La interfaz común podía viajar entre servidores, pero esa portabilidad tenía límites.

La documentación de mod_cgi de Apache sirve como ejemplo de implementación, no como censo de la web. Muestra cómo una familia de servidores selecciona scripts mediante controladores o ScriptAlias y devuelve su salida al cliente. Ese mecanismo ilustra la entrega; no altera la afirmación del RFC sobre el final de TLS ni demuestra cómo se configuraban todos los servidores.

El logro histórico de CGI fue una frontera compartida, no un proceso común ni un canal de seguridad de extremo a extremo. Servidor y script cooperaban mediante una interfaz con nombre, pero seguían siendo principales distintos con responsabilidades diferentes. Leer el RFC así evita un error de categoría: una solicitud protegida entre navegador y servidor no se convierte automáticamente en una relación protegida entre navegador y aplicación. RFC 3875 hizo explícita esa separación; no la eliminó.

Fuentes