1. Introduction
1. Introduction
Un modèle de déploiement assez courant pour les applications HTTPS consiste à placer les serveurs d'application HTTP d'origine derrière un proxy inverse qui termine les connexions TLS des clients. Le proxy est accessible depuis Internet et distribue les requêtes des clients vers le serveur d'origine approprié dans un réseau privé ou protégé. Les serveurs d'origine ne sont pas directement accessibles par les clients et ne sont accessibles que via le proxy inverse. Les détails backend de ce type de déploiement sont généralement opaques pour les clients qui font des requêtes au serveur proxy et voient les réponses comme si elles provenaient du serveur proxy lui-même. Bien que HTTPS soit également généralement utilisé entre le proxy et le serveur d'origine, la connexion TLS que le client établit pour HTTPS n'est qu'entre lui-même et le serveur proxy inverse.
Le modèle de déploiement se trouve dans un certain nombre de variétés telles que les architectures à n niveaux (n-tier architectures), les réseaux de diffusion de contenu (content delivery networks), les services d'équilibrage de charge d'applications (application load-balancing services) et les contrôleurs d'entrée (ingress controllers).
Bien que ce ne soit pas excessivement répandu, l'authentification par certificat client TLS (TLS client certificate authentication) est parfois employée, et dans de tels cas le serveur d'origine nécessite souvent des informations sur le certificat client pour sa logique applicative. Une telle logique peut inclure des décisions de contrôle d'accès, la journalisation d'audit, et la liaison de jetons (tokens) ou de cookies émis à un certificat, y compris la validation respective de ces liaisons. Les détails spécifiques nécessaires du certificat varient également selon les exigences de l'application. Pour que ces types de déploiements d'applications fonctionnent en pratique, le proxy inverse doit transmettre des informations sur le certificat client au serveur d'application d'origine. Au moment de la rédaction, une façon courante de transmettre ces informations consiste à utiliser des champs non standard (non-standard fields) pour transporter le certificat (dans un certain encodage) ou des parties individuelles de celui-ci dans la requête HTTP qui est distribuée au serveur d'origine. Cette solution fonctionne, mais l'interopérabilité entre des composants développés indépendamment peut être lourde ou même impossible selon les choix d'implémentation respectivement effectués (comme quels noms de champs sont utilisés ou configurables, quelles parties du certificat sont exposées, ou comment le certificat est encodé). Une approche prévisible bien connue de cette fonctionnalité courante pourrait améliorer et simplifier l'interopérabilité entre les implémentations indépendantes.
La portée de ce document est de décrire la pratique existante tout en codifiant des détails spécifiques suffisants pour faciliter une interopérabilité améliorée et à moindre contact. En tant que tel, ce document décrit deux champs d'en-tête HTTP, "Client-Cert" et "Client-Cert-Chain", qu'un proxy inverse terminant TLS (TLS Terminating Reverse Proxy, TTRP) ajoute aux requêtes envoyées aux serveurs d'origine backend. La valeur du champ Client-Cert contient le certificat client d'entité terminale (end-entity client certificate) de la connexion TLS mutuellement authentifiée entre le client d'origine et le TTRP. En option, la valeur du champ Client-Cert-Chain contient la chaîne de certificats (certificate chain) utilisée pour la validation du certificat d'entité terminale. Cela permet au serveur d'origine backend d'utiliser les informations du certificat client dans sa logique applicative. Bien qu'il puisse y avoir des proxies ou des sauts (hops) supplémentaires entre le TTRP et le serveur d'origine (potentiellement même avec des connexions TLS mutuellement authentifiées entre eux), la portée du champ d'en-tête Client-Cert est intentionnellement limitée à exposer au serveur d'origine le certificat qui a été présenté par le client d'origine dans sa connexion au TTRP.