Un reverse-proxy Apache pour accéder à de vieux serveurs en SSLv3

La faille POODLE a entraîné la désactivation du protocole SSLv3 dans tous les navigateurs récents.

Problème : que faire pour de vieux services HTTPS qui ne savent pas faire mieux que du SSLv3?
Les navigateurs récents refusent d’y accéder,  donc il faudrait les patcher/reconfigurer pour qu’ils prennent en charge des protocoles plus sécurisés. Mais ce n’est pas toujours possible : soit parce que ces applications web ne sont plus supportées, soit parce que ce serait trop risqué ou coûteux.

Une solution de contournement peut être de mettre en place un reverse-proxy entre ces services et les navigateurs des utilisateurs.

Je suis tombé sur ce cas avec un serveur Oracle Enterprise Manager Grid Control 10g.
Lors de l’installation, l’utilisation du https était apparemment obligatoire. Mais, dans sa configuration par défaut, il ne sait pas gérer de protocole plus récent que le SSLv3.

Symptôme : le message d’erreur suivant dans Firefox (et quelque chose d’analogue pour les autres navigateurs) :

Erreur SSL

Une erreur est survenue pendant une connexion à nom_serveur:1159. Le pair SSL a rejeté un message d’établissement de liaison à cause d’un contenu inacceptable. (Code d’erreur : ssl_error_illegal_parameter_alert)

Cette version 10g n’est plus supportée par Oracle (cf http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf), qui ne propose donc pas de correctif pour cela.

Dans un premier temps, j’ai essayé de modifier la configuration du serveur HTTP inclus dans ce produit (qui est apparemment basé sur un Apache 1.3).
Normalement, Apache 1.3 sait gérer le TLSv1 mais, après quelques tests de configuration, je n’ai pas réussi. Peut-être que je n’ai simplement pas cherché assez longtemps.

Mais finalement j’ai pensé à une autre solution : mettre un reverse-proxy Apache en frontal de ce serveur, qui saura communiquer avec les navigateurs via des protocoles plus récents.

Vieux serveur —SSLv3—> Reverse Proxy Apache —TLS—> Navigateur récent

L’avantage de cette solution est qu’elle est relativement générique : elle peut s’appliquer à n’importe quel service HTTP (pour peu qu’il soit compatible avec un reverse-proxy en frontal : ce n’est pas systématiquement le cas).

Pour ne pas s’exposer à des problèmes de sécurité, il faut l’installer sur le même serveur (ou accepter le risque d’interception entre les 2).

  • activer les modules ssl, proxy et proxy_http sur Apache
  • installer un certificat ssl valide, et le configurer pour qu’Apache l’utilise sur un port disponible (443 ou autre)
  • configurer le reverse proxy dans Apache. Voici la configuration que j’ai utilisée :
# Configuration du reverse-proxy pour l'Oracle Grid
ProxyRequests Off
<Proxy *>
    Require all granted
</Proxy>

ProxyPass / https://nom_machine:1159/
ProxyPassReverse / https://nom_machine:1159/
SSLProxyEngine on
# Je force le protocole SSLv3, qui a des failles de sécurité connues (poodle), mais Oracle Grid 10g ne sait pas gérer mieux
SSLProxyProtocol +SSLv3
# Dans mon cas de figure, le certificat d'Oracle Grid est auto-signé donc il faut ignorer tous les contrôles dessus
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off

Ainsi, en passant par le reverse-proxy, on retrouve l’accès au serveur concerné, tout en utilisant un protocole sécurisé.

NB : pour une raison que j’ignore, cela ne fonctionnait pas si je mettais localhost à la place du nom de la machine : peut-être qu’Oracle Grid fait des choses particulières s’il est accédé en localhost?

Un inconvénient à prendre en compte néanmoins : un très léger overhead CPU sur le serveur, du fait qu’il doit faire 2 cryptages SSL/TLS successifs. Dans mon cas de figure, le nombre d’utilisateurs était suffisamment restreint pour que ce soit négligeable.

Par contre, l’avantage est de ne pas toucher du tout à l’applicatif.

J’ai utilisé une version 2.4.4 d’Apache (sur Windows 2003 32 bits, le système d’exploitation qui porte Oracle Grid dans ce contexte), compilée avec OpenSSL 1.0.1e. Cela fonctionnait aussi sur une 2.2.25 (compilée avec OpenSSL 0.9.8y), mais pas sur une 2.4.10 ou 2.4.12 de ApacheHaus (dans lesquelles le support SSLv3 est peut-être complètement désactivé?). Cela limite a priori la sécurité de cette solution sur le long terme (si on ne peut effectivement pas upgrader Apache).

En l’occurrence, ce service Oracle Grid 10g ne va pas être conservé très longtemps, donc l’objectif était surtout de rétablir la fonctionnalité avec une solution temporaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *