Reverse proxy sur https

Support Debian
#1

Bonjour à tous,

Je souhaiterais mettre en place un reverse proxy avec squid de cette manière :

[WAN]--[ROUTEUR]--[PROXY]--[SERVEUR WEB 1] |----[SERVEUR WEB 2] |----[SERVEUR WEB 3] |----[SERVEUR WEB n]

Je n’ai qu’une adresse IP publique, et j’utilise du NAT pour redirigé vers le traffic sur le proxy.
Le proxy est configurer pour du virtualhost, et tout fonctionne parfaitement en http.

Aujourd’hui, je dois rajouter des serveurs Web en https (1 serveur exchange + 1 serveur apache).

Les tutoriels trouvés sur internet re-créés un certificat SSL sur le serveur proxy et communique après avec les serveurs WEB derrière (en https ou non d’ailleurs).

Pour ma part, j’aimerais ne pas re-créer de certificat SSL auto-signé (le serveur Web apache à un certificat d’une autorité reconnu), et transmettre directement les requêtes qui arrive sur les serveurs web respectifs. Le proxy n’as normalement pas besoin de voir ce qui transite, (le cache ne m’intéresse pas dans ce cas de figure) puisqu’en SSL, seul le payload est chiffré, les en-têtes http sont en clairs.

En résumé, je veux juste qu’il agisse comme un simple routeur, et qui redirige le traffic sur les bons serveurs sans se préoccuper de ce qu’il y a dedans ?

Es-ce possible ?

PS : J’ai déjà regardé sur côté d’apache, je ne désire pas utilisé le module proxy.

Cordialement,

#2

En HTTPS tout est chiffré, y compris les en-têtes HTTP (donc le champ Host: contenant le nom du site) évidemment. Le contraire constituerait une faille de sécurité.

Il y a deux approches pour un serveur web ou reverse proxy servant plusieurs domaines en HTTPS sur la même adresse IP et le même port :

  • fournir au client un certificat unique contenant tous les domaines (via subjectAltName) ;
  • fournir au client le certificat correspondant au site demandé via l’extension TLS SNI (Server Name Indication). Il faut alors que le client et le serveur/proxy supportent tous les deux SNI.

Comment mettre en oeuvre l’un ou l’autre avec squid est hors de mes connaissances.

#3

Oups, autant pour moi. Du coup les en-têtes https sont bien chiffrées,

Tu peux juste éclairer ma lanterne, si j’ai bien compris :

  • Les en-têtes http/https transite dans la partie data du datagramme IPv4
  • Les en-têtes IPv4 ne sont pas chiffrées dans le cadre d’un chiffrement SSL (ce qui permet donc de faire du NAT par exemple)
  • Dans le cadre d’une solution VPN telle que IPSec utilisant ESP, le paquet complet (dont les en-têtes) sont chiffrées ce qui pose problème pour faire du NAT

[quote=“PascalHambourg”]Il y a deux approches pour un serveur web ou reverse proxy servant plusieurs domaines en HTTPS sur la même adresse IP et le même port :

  • fournir au client un certificat unique contenant tous les domaines (via subjectAltName) ;
  • fournir au client le certificat correspondant au site demandé via l’extension TLS SNI (Server Name Indication). Il faut alors que le client et le serveur/proxy supportent tous les deux SNI.

Comment mettre en oeuvre l’un ou l’autre avec squid est hors de mes connaissances.[/quote]

Je ne connais pas SNI, je vais aller me documenter là dessus, merci beaucoup

#4

Et même dans la partie données du segment TCP contenu dans le paquet IP (v4 ou v6).

Ni les en-têtes TCP. Seules les données de la charge utile TCP le sont.

L’en-tête IP n’est pas chiffré, sinon il serait impossible de router le paquet puisque l’en-tête IP contient notamment l’adresse de destination. Par contre (presque [*]) tout le paquet est authentifié par l’émetteur. Donc si on le modifie en chemin, le destinataire le verra et le rejettera. L’encapsulation d’IPSec dans UDP (NAT-T) permet de faire du NAT car les en-têtes UDP/IP ne sont pas vérifiées.

[*] Certains champs comme le TTL sont susceptibles d’être modifiés par les routeurs en chemin.

#5

Et même dans la partie données du segment TCP contenu dans le paquet IP (v4 ou v6).

Ni les en-têtes TCP. Seules les données de la charge utile TCP le sont.

L’en-tête IP n’est pas chiffré, sinon il serait impossible de router le paquet puisque l’en-tête IP contient notamment l’adresse de destination. Par contre (presque [*]) tout le paquet est authentifié par l’émetteur. Donc si on le modifie en chemin, le destinataire le verra et le rejettera. L’encapsulation d’IPSec dans UDP (NAT-T) permet de faire du NAT car les en-têtes UDP/IP ne sont pas vérifiées.

[*] Certains champs comme le TTL sont susceptibles d’être modifiés par les routeurs en chemin.[/quote]

Merci beaucoup pour ces éclaircissements :slightly_smiling:

Pour ma part j’essaye de trouver une solution et je poste si j’ai quelque chose :wink:

#6

Pour répondre à ma question :

Je n’ai pas trouvé de moyen de mettre un certificat par sous domaine. Cependant, il visiblement (je n’ai pas fait les tests) possible d’utilise un certificat de class 2 qui vérifié non pas le nom de domaine, mais l’organisation. Ainsi lorsque l’on se connecte quelques soit le sous domaine du domaine principal, le site est validé (pas d’erreur de certificat)