Commentaires sur : Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS

Par : thio

thio — Fri, 18 Nov 2011 14:56:20 +0000

Bonjour,
Merci pour l’article; il m’a permis de mettre en place ssl dans mon serveur apache en frontal lié à tomcat. Ainsi toutes mes applications simples (avec jsf,jsp,servlet) marchent et me renvoient le résultat attendu de l’url https://localhost/MonApp.
Cependant, tout n’est pas rose car avec mon application qui prévoit une architechture acegi pour l’authentification, je n’arrive pas à avoir de résultat et pour les deux navigateus chrome et firefox voici le meme résultat:

Bad Request
Your browser sent a request that this server could not understand.
Reason: You’re speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Hint: https://localhost/

pour Internet explorer

une alerte est déclenchée disant: « vous êtes sur le point d’accéder a des pages par une connexion securisée … » et je clique sur « ok »
Aussitôt après, une deuxième alerte s’érige: « la connexion que vous allez utiliser n’est pas sécurisée ».

Toutefois, la constante dans les trois navigateurs est que si continue à enfuire manuellement « https » (pendant trois a quatre fois) au début des urls oû je suis redirigé, toutes mes pages sont sous https et je n’ai plus besoin de les rentrer manuellement: quand j clique sur un lien ou bouton l’url est directement https?

Si vous avez rencontré ce problème, ce serait volontier que j’accepte votre aide. Merci

Par : thio

thio — Fri, 18 Nov 2011 12:58:15 +0000

Bonjour,
Merci pour l’article,il m’a permis de mettre en place mon serveur apache sécurisé lié a tomcat et tout marche comme sur des roulettes avec toutes mes applications simples : jsf, jsp, servlet. Donc avec https://localhost/MonApp me renvoie MonApp avec toutes ses pages sous https.
Cependant, avec une application d’architecture prévoyant acegi pour l’authantification,j’ai un problème:ça ne marche pas.
En effet, selon les navigateurs, voici mes résultats avec https://localhost/MyAppli:

Chrome: Bad Request
Your browser sent a request that this server could not understand.
Reason: You’re speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Hint: https://localhost/

Firefox:

400 Bad Request

Hint: https://localhost/

Internet Explorer:
Ici une première alerte arrive disant: » Vous etes sur le point de visualiser des pages sur une connexion sécurisée … » et je clique sur ok
Aussitôt après, une deuxième alerte s’érige: « La connexion que vous allez utiliser n’est pas sécurisée… » et je clique sur ok ya rien qui s’affiche juste du blanc.

La constante dans les trois navgateurs est que si je continue a enfuire manuellement, entre trois a quatre fois,https au début des urls ou je suis redirigé, le reste de mes pages est sécurisé https exemple: https://localhost/MyAppli/transaction.jsp
Maintenant j’aimerai bien que vous me donniez une idée car ca fait des jours que je suis bloqué à ce niveau.

Par : Séven Le Mesle

Séven Le Mesle — Mon, 26 Sep 2011 16:46:18 +0000

Bonjour Mathieu,

tout d’abord Apache est bien plus performant pour traiter le SSL que Tomcat. Cela permet donc de soulager les serveurs Tomcat de traitement lourd, ensuite, personnellement je considère que dans ce type de configuration, les serveurs Tomcat sont dans un réseaux de confiance en dehors de la DMZ et donc que les données sensibles ne sont pas mises en péril.
Les login et mot de passe peuvent très bien être transmis au Tomcat dans le cas présenté ci-dessus c’est d’ailleurs ce que j’avais fait à l’époque chez mon client. J’utilisais aussi Spring-Security pour réaliser l’authentification.
Encore un avantage que je trouve à cette configuration, est de simplifier très largement l’analyse en cas de problème car dumper une requête HTTP en clair permet de voir réellement ce qui se passe entre les serveurs.
Je conseillerai tout de même de faire attention aux logs car on retrouve très facilement les login et mot de passe qui y apparaissent.
Typiquement si vous faites du GET pour l’authentification avec les paramètres dans l’URL, par défaut ils apparaîtront dans les access log Tomcat.

Merci d’avoir lu cet article et merci encore pour cette question.

Par : Mathieu

Mathieu — Mon, 26 Sep 2011 15:14:25 +0000

Bonjour et merci pour votre article que j’ai lu avec attention.
J’aimerais savoir quel est l’intérêt de sécuriser Tomcat de la manière décrite dans cet article ?
En effet, il me semble (sauf si j’ai loupé qqchose) que la communication entre Apache et Tomcat reste du HTTP et donc que les données sont transmises en clair, non ? Si c’est le cas, quel est l’apport de la sécurisation décrite ici ?
Je me pose la question car je dois mettre en place une appli avec un serveur apache en frontal de 2 tomcat qui héberge des webapps dont l’accès (au niveau applicatif) est sécurisé par spring-security (via login/password et ldap), et donc dans mon cas, les données d’authentification sont transmises jusqu’au Tomcat.
Merci d’avance.

Par : Bruno Harbulot

Bruno Harbulot — Fri, 25 Jun 2010 17:05:54 +0000

Pour info, sur les certificats clients, une des differences entre mod_jk et mod_proxy est que mod_proxy ne fait passer que le premier certificat de la chaine envoyee par le client (le certificat client lui-meme), et pas toute la chaine (alors que mod_jk le peut):

http://www.mail-archive.com/dev@httpd.apache.org/msg41660.html

(Ca n’est un probleme que si on a besoin de la chaine, bien sur.)

Par : hgomez

hgomez — Mon, 12 Oct 2009 14:02:20 +0000

Ayant contribué quelques années à mod_jk, j’ai lu cet article avec intérêt. Je m’interroge souvent sur ce rejet de mod_jk qui est souvent décrié alors qu’il fonctionne bien et permet des configurations très diverses, du simple lien HTTP->Tomcat jusqu’à des modes load-balancing très élaborés.

Le seul manque de mod_jk est la découverte de la topologie d’une grappe de Tomcat distantes et l’ajustement dynamique à l’entrée/sortie de membres dans la grappe et ce sont des points qui ne sont pas couverts par mod_proxy mais plutôt par le projet JBoss mod_cluster (http://jboss.org/mod_cluster/).

Par : Benoît

Benoît — Fri, 25 Sep 2009 07:40:21 +0000

@Séven

Vous m’avez persuadé qu’il faut que je refasse une analyse en partant sur les versions actuelles pour reévaluer les arguments en faveur de l’une ou l’autre option.

Quoiqu’il en soit merci pour l’article.

Remarque :
Websphere contient en interne un fork d’une version antérieure de Apache (IHS) et Tomcat (Websphere à proprement parlé), et la communication entre les deux est assurée en HTTP + spécifique (comme le mode proxy dont on parle), comme le mod_proxy.

Par : Séven Le Mesle

Séven Le Mesle — Thu, 24 Sep 2009 18:28:30 +0000

Bonsoir Benoît,
pour ce qui est de l’utilisation d’attributs de certificats spécifiques, je ne saurai me prononcer. J’avoue ne pas avoir beaucoup utilisé ce type d’authentification. Dans le même registre, je n’ai pas fait les benchs pour comparer les performances des deux modules. Je peux juste dire que dans la documentation actuel de Tomcat, il est recommandé d’utiliser le mod_jk pour améliorer les performances précisément. Cela dit, la performance de la solution utilisant le mod_proxy doit pouvoir être au moins amélioré en utilisant la compression gzip pour limiter la quantité de données qui transite entre les deux serveurs.
Par contre, je pense qu’il est parfaitement envisageable d’appliquer la même méthode que dans l’article pour assurer que le remoteUser soit renseigné correctement sur la requête.

Par : Benoît

Benoît — Thu, 24 Sep 2009 12:09:09 +0000

[cite Séven Le Mesle]
Cela a le mérite de sécuriser correctement l’accès aux pages sans pour autant remonter les informations utiles du certificat au niveau applicatif. Pour contourner ce problème, il suffit d’utiliser le mod_headers qui va permettre d’ajouter dans les entêtes de la requête les informations du certificat dont l’application a besoin.
[/cite]

Cela présente les inconvénients suivants :
- devoir faire une configuration spécifique (pour le mod_headers) au cas où il y a des attributs du certificat spécifiques à une infrastructure donnée ;
- il faut modifier l’applicatif en fonction de l’infrastructure, puisque quelque chose de standard (le certificat qu’on récupère par request.getRemoteUser() …) devient quelque chose de spécifique (request.getHeader(« myCertifiedUserLoginKey »)).

En ce qui concerne les arguments présentés dans les slides de Covalent (merci pour le lien très intéressant), je suis sensible à ceux expliquant que HTTP c’est du texte (donc lisible pour l’éternité et autre avantages), et que c’est un standard tellement répandu qu’il existe pléthore d’outils permettant de travailler avec, mais j’ai du mal à croire que l’overhead du mod_http par rapport au mod_jk soit négligeable parce qu’on a moins de travail de marshalling/unmarshalling. Quand j’avais fait des tests (il y a six ans, soit, et dans une configuration bien précise !) le gain à utiliser mod_jk était tel que l’on ne pouvait même pas se poser la question (du simple au double, de mémoire, en gros).

Par : Séven Le Mesle

Séven Le Mesle — Thu, 24 Sep 2009 10:18:35 +0000

Bonjour et merci pour ce petit rappel à l’ordre.

Pour assurer l’authentification des certificats clients avec le mod_proxy_http, il faut tout d’abord activer la dite authentification sur le proxy apache. Avec Apache il est tout à fait possible de forcer la présentation d’un certificat client valide. Cela a le mérite de sécuriser correctement l’accès aux pages sans pour autant remonter les informations utiles du certificat au niveau applicatif. Pour contourner ce problème, il suffit d’utiliser le mod_headers qui va permettre d’ajouter dans les entêtes de la requête les informations du certificat dont l’application a besoin.

Par : Piwaï

Piwaï — Thu, 24 Sep 2009 07:52:38 +0000

Intéressant, et les arguments en faveur de mod_proxy paraissent fondés. Cependant quelqu’un a t’il une réponse à apporter à la question de Benoît portant sur l’authentification forte et la propagation du certificat client jusqu’à Tomcat ?

Par : Séven Le Mesle

Séven Le Mesle — Wed, 23 Sep 2009 17:34:57 +0000

Bonjour et merci pour ces commentaires,
effectivement, plusieurs arguments ont déjà été avancés sur ce choix. J’ajoute tout de même que contrairement au mod_proxy, le mod_jk ne fait pas parti de la distribution officielle d’Apache. La configuration est aussi beaucoup plus simple avec le mod_proxy. Notez ensuite que le protocole AJP n’est pas aussi répandu que le protocole HTTP. L’utilisation d’un proxy HTTP est donc portable vers des solutions ne supportant pas AJP. Quelque soit le backend, la même configuration pourra être appliquée, ce qui simplifiera grandement le travail d’administration.
Dernier avantage déjà mentionné dans l’article, avec HTTP il est facile d’analyser le trafic entre le frontend et le backend ce qui n’est pas possible avec un protocole binaire comme AJP.

Par : Thibaud

Thibaud — Wed, 23 Sep 2009 16:45:38 +0000

Xebia avait déjà publié dans une revue de presse un paragraphe sur « la mort » de mod_jk avec des arguments :
http://blog.xebia.fr/2008/08/25/revue-de-presse-xebia-71/

A vous de voir.

Par : Benoît

Benoît — Wed, 23 Sep 2009 13:47:45 +0000

Bonjour,

J’aimerais bien savoir quel sont les arguments qui iraient en faveur du mod_proxy/HTTP plutôt que le mod_jk/AJP. Mon expérience est plutôt qu’on préconise le second, et on essaie de gérer le premier s’il y a des impératifs externes (dus aux contraintes du SI des clients) qui le nécessitent.

Par exemple, en utilisant mod_proxy au lieu de mod_jk, il y a un problème d’architecture si on veut un utiliser HTTPS avec authentification client (et non plus authentification serveur uniquement), c’est-à-dire pour faire de l’authentification forte. En effet, si la connexion entre Apache et Tomcat est en HTTP, il n’est pas possible de récupérer au niveau de Tomcat, et donc au niveau applicatif, les informations du certificat client, donc a fortiori, son authentification.

Je me permet de réagir, parce que j’ai fréquemment eu à faire du support, voire à écrire des contournements applicatifs parce que cet impératif (et non pas choix) d’architecture a été imposé sur des projets.