4. Security Considerations (Considérations de sécurité)
4. Security Considerations (Considérations de sécurité)
Les champs d'en-tête décrits ici permettent à un TTRP et à un serveur backend ou d'origine de fonctionner ensemble comme s'ils étaient, du point de vue du client, un déploiement logique unique côté serveur de HTTPS sur une connexion TLS mutuellement authentifiée. Cependant, l'utilisation des champs d'en-tête en dehors de ce cas d'utilisation prévu peut compromettre les protections offertes par l'authentification par certificat client TLS. Par conséquent, des mesures telles que celles décrites ci-dessous doivent être prises pour prévenir une utilisation non intentionnelle, tant lors de l'envoi du champ d'en-tête que lors de la dépendance à sa valeur.
La production et la consommation des champs d'en-tête Client-Cert et Client-Cert-Chain DEVRAIENT être des options configurables, respectivement, dans un TTRP et un serveur backend (ou dans une application individuelle sur ce serveur). La configuration par défaut pour les deux devrait être de ne pas utiliser les champs d'en-tête, nécessitant ainsi un "opt-in" à la fonctionnalité.
Afin de prévenir l'injection de champ (field injection), les serveurs backend DOIVENT seulement accepter les champs d'en-tête Client-Cert et Client-Cert-Chain d'un TTRP de confiance (ou d'un autre proxy dans un chemin de confiance depuis le TTRP). Un TTRP DOIT nettoyer la requête entrante avant de la transmettre en supprimant ou en écrasant toutes les instances existantes des champs. Sinon, des clients arbitraires peuvent contrôler les valeurs de champ telles qu'elles sont vues et utilisées par le serveur backend. Il est important de noter que négliger de prévenir l'injection de champ ne "échoue pas en toute sécurité" (fail safe) dans la mesure où la fonctionnalité nominale fonctionnera toujours comme prévu même lorsque des actions malveillantes sont possibles. En tant que tel, une attention particulière est recommandée pour s'assurer qu'un nettoyage approprié des champs est en place.
La communication entre un TTRP et un serveur backend doit être sécurisée contre l'écoute et la modification par des parties non intentionnelles.
Les options de configuration et le nettoyage des requêtes sont des fonctionnalités nécessaires des serveurs respectifs. Les autres exigences peuvent être satisfaites de plusieurs façons, qui varieront en fonction des déploiements spécifiques. La communication entre un TTRP et un serveur backend ou d'origine, par exemple, pourrait être authentifiée d'une manière ou d'une autre avec l'insertion et la consommation des champs d'en-tête Client-Cert et Client-Cert-Chain se produisant uniquement sur cette connexion. L'Annexe B.3 de [HTTPSIG] donne un exemple de cela avec une application de signatures de messages HTTP (HTTP Message Signatures). Alternativement, la topologie du réseau pourrait dicter un réseau privé tel que l'application backend ne puisse accepter que les requêtes du TTRP et le proxy ne puisse faire des requêtes qu'à ce serveur. D'autres déploiements qui répondent aux exigences énoncées ici sont également possibles.