Un relais est un point de regroupement de flux réseau, généralement associé à plusieurs clients. C'est ainsi que l'on trouve des relais HTTP, souvent associés à des caches. Ces relais se substituent aux outils des utilisateurs (par exemple les navigateurs des collaborateurs d'une entreprise, ou les abonnés d'un FAI) afin d'émettre les requêtes vers les serveurs HTTP, et renvoient aux utilisateurs les informations obtenues.

L'avantage d'un relais est de canaliser les échanges (point de passage obligé, sous réserve d'avoir mis en place les filtres réseaux appropriés), avec les possibilités que cela offre du point de vue des contrôles que l'on peut y faire. Dans la majorité des cas, le relais HTTP est un point de regroupement et d'éclatement des flux : N clients contactent 1 relais qui peut contacter M serveurs HTTP.

Certains relais peuvent n'avoir pour vocation que de canaliser les échanges vers un seul serveur. Typiquement, le relais de messagerie entrant joue ce rôle. M systèmes peuvent le contacter (émission de messages à destination de l'entreprise), et ce relais ne dialogue qu'avec le serveur de messagerie interne (lequel peut aussi relayer les messages vers des serveurs départementaux, mais c'est une autre histoire).

Relais inverse HTTP

Le système de relayage a pour but de canaliser les flux HTTP à destination d'un serveur réel, lequel n'est alors plus joignable directement depuis Internet (ou depuis une zone considérée à risques de votre réseau).

Ce mode de fonctionnement, dans sa configuration la plus élémentaire, permet de protéger un serveur HTTP derrière un relais, ce dernier étant configuré au plus strict. On occulte complèment le serveur réel au profit d'un relais plus réduit et plus léger.

L'intérêt est évident :

• Les utilisateurs contactent un serveur HTTP dont les fonctionnalités ont été réduites au strict minimum.
• On crée un canal restreint par lequel tous les échanges avec le "véritable" serveur Web doivent passer.

La restriction des fonctionnalités du relais permet de minimiser les risques applicatifs ou de mauvaise configuration. S'il est bien installé et configuré, le relais ne sait pas faire autre chose que relayer vers d'autres systèmes. Par exemple, si l'on utilise un serveur Apache en tant que relais inverse, il est suffisant de n'activer que quelques-uns des modules standard. Les fonctions évoluées (CGI, négociation de la langue, suivi des utilisateurs, etc.) sont inutiles et donc non-intégrées au relais. Leur absence totale du système permet d'éviter qu'elles ne soient accidentellement activées ultérieurement.

Le relais inverse est le seul système autorisé à dialoguer avec les véritables serveurs. Cela permet de configurer ces derniers afin qu'ils n'acceptent de requêtes que si elles viennent du relais inverse. Ainsi, il devient difficile de contourner les contrôles mis en place par le relais (s'il y en a). Si les fonctionnalités du service Web ont été réparties sur plusieurs serveurs (le relais inverse jouant le rôle d'aiguilleur), la surveillance des systèmes opérationnels les plus sensibles en est facilitée :

• Inutile de surveiller finement les flux vers le serveur d'images, qui ne fournit que du contenu statique.
• Le serveur de pages est plus surveillé car il traite des informations issues des utilisateurs (cookies, paramètres de certaines URLs, etc.).
• Les flux avec le serveur de programmes sont contrôlés très finement (volumes transmis, contenus, etc.)

Outre ces premiers avantages, il est possible :

• De mettre en place un filtrage des URLs demandées, selon des critères plus ou moins élaborés.
• De diriger les requêtes vers des serveurs différents, selon les situations (serveur d'images, de programmes, etc.).
• De filtrer les paramètres transmis aux programmes.

Toutes ces opérations sont transparentes pour l'internaute, qui n'a jamais l'impression de dialoguer avec des systèmes différents. Pour lui, il est en train de discuter avec "le" serveur HTTP, même lorsque ses requêtes sont réacheminées vers plusieurs systèmes différents.

Relais inverse et SSL

Dans beaucoup de cas, une partie des échanges entre le navigateur de l'internaute et le serveur est chiffrée. On pense bien entendu aux sites de commerce électronique, mais tout échange d'informations jugées confidentielles peut être protégé par SSL. Ainsi, la phase de connexion à un site, durant laquelle on demande le compte et le mot de passe, peut être chiffrée (même si le reste des échanges ne l'est pas).

Du point de vue du navigateur, le relais inverse est le véritable serveur. Le déchiffrement SSL se fait donc à ce niveau, et c'est sur le relais que les certificats sont installés. Le dialogue entre le relais inverse et les serveurs réels se fait en clair.

On peut juger que l'existence de ces dialogues en clair va à l'encontre du but même du chiffrement, qui est d'empêcher l'interception des informations (plus exactement, de la rendre inexploitable). Ce n'est pas réellement le cas, car le dialogue se fait sur des infrastructures privées et bien protégées (ce peut être un simple câble croisé reliant le relais inverse et le serveur réel). La probabilité d'interception est considérablement réduite par rapport au cheminement d'un paquet sur Internet, qui peut être intercepté sur n'importe quel brin réseau par lequel il transite.

Cette garantie n'est pas forcément suffisante. Dans ce cas, le relais inverse peut dialoguer en SSL avec le ou les serveurs réels. Cela suppose que d'autres certificats valides ont été installés sur les serveurs réels.