Comment gérer les connexions http chiffrées et non chiffrées via un seul port

10

Veuillez regarder le schéma suivant.

texte alternatif

Comment cela devrait-il fonctionner?

  • Lorsqu'un distant demande http: // myhost.com:8080/*, la demande doit être transmise au serveur http qui écoute sur le port 8008 de l'interface de bouclage. C'est la partie facile.

  • Lorsqu'un utilisateur distant demande http: // myhost.com:8080/specialurl ...

    • Le programme agissant comme une passerelle au niveau de l'application doit pouvoir mettre à niveau la connexion vers une session chiffrée ( sans changer de port )

    • Après avoir établi une session chiffrée avec le navigateur distant, il doit transmettre la demande au programme C qui écoute sur le port 8000 de l'interface de bouclage

Mes questions sont :

  1. Avez-vous déjà déployé une solution comme celle-ci sur un environnement de production? Si tu as...
  2. Quel produit avez-vous utilisé pour servir de passerelle d'application?
  3. Pourriez-vous fournir un exemple de configuration?

Restrictions strictes :

  • Je n'ai pas de contrôle sur le pare-feu , et le seul port par lequel je peux obtenir du trafic externe vers le serveur interne est 8080. Le numéro de port n'est pas pertinent, le fait est qu'il n'y a qu'un seul port ouvert au niveau du pare-feu qui transmet les messages entrants le trafic vers le serveur interne.
  • Le serveur interne doit exécuter Linux (actuellement il exécute Debian Lenny)
  • Les utilisateurs distants ne devraient avoir besoin que d'un navigateur Web et d'une connexion Internet pour accéder à ce serveur. Cela signifie que la redirection de port inverse via SSH n'est pas une option ici.
  • J'ai besoin d'un produit qui a été testé en production et qui peut être facilement déployé. Je ne cherche pas à développer ma propre passerelle d'application (si tel était le cas, je suppose que je poserais cette question à Stack Overflow au lieu de la poser à Server Fault).

Restrictions douces :

  • Je voudrais éviter de mettre Apache comme passerelle d'application (même si je suis prêt à le faire si c'est le seul choix possible)
  • Si possible, la passerelle d'application doit être un produit logiciel open source mature.

Produits essayés jusqu'à présent comme passerelles d'application (sans succès)

  • nginx
  • lighttpd
  • livre

RFC pertinents

  • RFC2817 (... explique comment utiliser le mécanisme de mise à niveau dans HTTP / 1.1 pour lancer Transport Layer Security (TLS) sur une connexion TCP existante. Cela permet au trafic HTTP non sécurisé et sécurisé de partager le même port bien connu ...)
  • La RFC2818 (... décrit comment utiliser TLS pour sécuriser les connexions HTTP sur Internet. La pratique actuelle consiste à superposer HTTP sur SSL (le prédécesseur de TLS), en distinguant le trafic sécurisé du trafic non sécurisé par l'utilisation d'un port de serveur différent ... )
alemartini
la source
"Lorsqu'un utilisateur distant demande http: // myhost.com:8080/specialurl ... Le programme agissant comme une passerelle de niveau application doit pouvoir mettre à niveau la connexion vers une session chiffrée (sans changer de port)" ... comment est est-ce possible du côté client? Un navigateur client prend-il en charge l'exécution de SSL via une URL qui ne contient pas https?
Adam Brand
Salut Adam et merci d'avoir laissé ton commentaire. Après avoir demandé myhost.com:8080/specialurl , le navigateur doit être redirigé vers myhost.com:8080/specialurl . Je ne suis pas sûr des autres navigateurs, mais les versions récentes d'Opera et de Firefox semblent le supporter sans problème.
alemartini

Réponses:

1

Un port pour les gouverner tous, montre que quelqu'un l'a au moins implémenté dans le monde Java.

Avez-vous déjà déployé une telle solution dans un environnement de production?

Je ne l'ai pas fait - et je ne recommanderais jamais que cela soit fait. En tant que consultant, j'essaie d'encourager mes clients à utiliser des technologies standardisées et éprouvées. Aucun système ne semble implémenter correctement ces RFC, à l'exception des cas marginaux - et ce ne serait pas quelque chose que je voudrais suggérer ou soutenir.

SirStan
la source
Salut Stan, et merci pour les commentaires. Je ne connaissais pas Grizzly, et malheureusement je ne connais pas Java. Avez-vous déjà déployé une telle solution dans un environnement de production? Ce serait formidable si vous pouviez partager un exemple montrant comment le faire. Merci encore, Alex.
alemartini
Ok, merci d'avoir édité votre réponse et ajouté plus d'informations. Comme vous pouvez le voir, j'ai maintenant resserré ma question, déclarant plus clairement que je recherche un produit mature. Voyons voir si quelqu'un trouve une bonne réponse à celle-ci. Il est difficile de croire qu'Apache est la seule et unique application du monde Linux qui prend en charge RFC2817. Mais si c'est le cas, ou si personne d'autre n'a une expérience réelle du déploiement de quelque chose comme ça avec un autre produit, je pense que je n'aurai pas d'autre choix que d'essayer de résoudre ce problème avec Apache.
alemartini
0

Apache ne vous aidera pas ici. Il ne peut écouter que les connexions HTTP ou HTTPS (pas les deux) sur un port donné.

Pour autant que je sache, il n'y a pas de "produit mature" qui implémente cette fonctionnalité. Demandez à votre administrateur réseau de vous percer un autre trou dans le pare-feu, ou configurez un tunnel VPN ou SSH vers un point de terminaison externe où vous pouvez configurer plusieurs ports d'écoute.

duskwuff -inactif-
la source