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

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).