Résumé

  • CGI/1.1 a défini un échange commun de requête et de réponse entre serveur HTTP et script, tout en laissant certains détails dépendre du système ou de l’implémentation.
  • La RFC 3875 situait TLS entre le client et le serveur : le client authentifiait le serveur, tandis que le script ne recevait aucune preuve intégrée de l’identité de son appelant ni de l’intégrité du message CGI.

La connexion est sécurisée. L’application n’est pas nécessairement à l’autre bout.

C’est la frontière discrète de la RFC 3875, la spécification CGI (Common Gateway Interface) Version 1.1 publiée en 2004. Un navigateur peut établir TLS avec un serveur web. Celui-ci peut ensuite transmettre les données de la requête à un programme CGI. Mais la relation de sécurité décrite par la RFC ne traverse pas intacte ce second passage. Le serveur est le pair réseau ; le script reste un processus applicatif derrière lui.

CGI rendait déjà des services bien avant la RFC 3875. Un serveur HTTP pouvait servir de passerelle vers une base de données ou un autre système d’information existant, tandis qu’un script composait une réponse à partir de la requête. La page historique du W3C décrit CGI comme un accord entre implémenteurs de serveurs pour intégrer ces scripts et programmes passerelles. Elle mentionne une tentative de mise à jour de CGI 1.1 en 1995, puis la relance, en novembre 1997, d’un effort visant à transformer une interface de fait en RFC informative. Le texte final a paru en octobre 2004 dans le flux indépendant.

Ce délai importe moins comme anecdote sur les normes que pour comprendre le projet du document. CGI était déjà une convention pratique. La RFC 3875 n’a pas inventé les applications web dynamiques ; elle a formalisé un contrat portable pour une requête qui devait passer d’un serveur exposé au réseau à un programme applicatif.

Ce contrat nomme des « méta-variables » comme REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, PATH_INFO et REMOTE_ADDR. Il définit la façon dont un script renvoie des en-têtes et un corps, y compris une page ou une redirection. Des programmes exécutés par des serveurs différents disposent ainsi d’un vocabulaire commun. Le texte répartit aussi les tâches : le serveur gère la connexion client, le transfert des données et le protocole réseau ; le script assure le travail applicatif, comme l’accès aux données et le traitement documentaire.

Cette division ne transfère pas les obligations du serveur. La RFC 3875 précise que, même si le script ne respecte pas la spécification, le serveur reste responsable envers le client de la conformité au protocole réseau. Elle impose également à un serveur qui applique une authentification de ne pas exécuter le script avant que la requête ait satisfait aux contrôles d’accès définis. Le serveur n’est pas un simple tuyau qui pourrait reprocher à son processus enfant une réponse invalide ou une vérification omise.

La section 9.4 resserre ensuite la frontière de confiance. Pour une connexion TLS, le modèle de sécurité s’applique entre client et serveur, et non entre client et script. Le client authentifie le serveur. La spécification ne fournit au script aucun mécanisme pour authentifier le serveur qui l’a invoqué et n’impose pas l’intégrité des messages CGI de requête et de réponse.

Cela ne signifie ni que le script doit être considéré comme hostile, ni qu’un opérateur ne peut protéger le processus local. Le serveur peut s’appuyer sur les permissions du système, un canal privé ou d’autres contrôles. Le point est plus limité : le TLS au bord HTTP n’authentifie pas à lui seul le script en aval comme s’il était le même pair. Si le script reçoit HTTPS=on ou un nom d’utilisateur dans son environnement, il reçoit des valeurs ; l’interface CGI ne lui fournit pas de preuve cryptographique reliant ces valeurs à une session client authentifiée.

L’architecture dépassait volontairement un modèle de processus unique. La RFC décrit le processus enfant exécuté sous l’utilisateur et le groupe du serveur comme l’implémentation la plus courante, tout en reconnaissant les scripts liés au serveur. Elle distingue les comportements « définis par le système » de ceux « définis par l’implémentation ». Le vocabulaire commun pouvait circuler entre serveurs, mais cette portabilité avait des limites.

La documentation Apache de mod_cgi illustre une implémentation, pas l’ensemble du Web. Elle montre comment une famille de serveurs sélectionne des scripts au moyen de gestionnaires ou de ScriptAlias, puis renvoie leur sortie aux clients. Cet exemple matérialise le passage ; il ne modifie pas la frontière TLS de la RFC et ne prouve pas comment tous les serveurs étaient configurés.

L’apport historique de CGI fut une frontière partagée, non un processus commun ou un canal de sécurité de bout en bout. Le serveur et le script coopéraient par une interface nommée, tout en restant des acteurs distincts aux responsabilités différentes. Lire la RFC ainsi évite une confusion de catégories : une requête protégée entre navigateur et serveur n’est pas automatiquement une relation protégée entre navigateur et application. La RFC 3875 rendait cette séparation explicite ; elle ne l’abolissait pas.

Sources