blog.bressure.net

En voulant intégrer Traefik dans mon architecture pour simplifier la définition de nouveau service en retirant le besoin de connaître le port d’exposition sur l’hôte, je me suis aperçu que les sites wordpress s’étaient mis à s’afficher bizarrement. Le navigateur m’indiquait que la page contenait à la fois du contenu en http et en https. C’est le fameux mixed content que les navigateurs récents considèrent comme un problème de sécurité. Dans les pages les liens vers les ressources de mise en forme (css) étaient alors bloquées.

X-forwarded-proto

J’avais été confronté à ce problème bien auparavant et que j’avais en premier lieu contourné appelant wordpress en HTTPS depuis mon frontal apache. Comme le frontal apache était lui-même une terminaison SSL, faire un appel https en interne dans mon infra ne me satisfaisait pas. D’autant plus que le certificat local du wordpress était autosigné et qu’il me fallait désactiver les contrôles de certificats par apache.

La solution est venu de l’ajout du header X-forwarded-proto avec valeur https dans la requêtes HTTP entre apache et wordpress pour que ce dernier génère des page avec des liens en HTTPS. En fait wordpress utilise ce header pour savoir si il est appelé par la client réel en HTTP ou en HTTPS. Dans le VirtualHost ssl de apache:

 RequestHeader set X-Forwarded-Proto "https"

Haproxy le proxy du proxy

Le schéma suivant montre l’ajout d’un haproxy pour la répartition de charge entre la terminaison SSL jouée par apache et le serveur wordpress.

Tout se passe comme prévue et le site wordpress continue à fonctionner normalement. Les pages sont bien générées avec des liens en HTTPS même si wordpress est accédé en HTTP. En enlevant la configuration X-forwarded-proto du apache, le site est signalé comme non sécurisé par le navigateur car les pages contiennent alors des liens en HTTP.

Traefik en proxy du proxy du proxy

En ajoutant Traefik entre le haproxy et le site wordpress, les choses se passent mal. Le navigateur signale le site comme non sécurisé avec des liens en HTTP dans la page. WordPress ne détecte pas le header qui doit lui indiqué de générer le site avec des liens HTTPS. Et pour cause, Traefik par défaut ne fait pas confiance au entête X-Forwarded-??? et les enlève avant de faire la requête à wordpress.

Le comportement de Traefik est respectueux de la sécurité en enlevant l’entête X-forwarded-proto par défaut. Le proxy en amont prétend avoir reçu une requête HTTPS en entrée, il a décrypté le flux et appelle Traefik en clair. Si ce proxy est compromis (n’oublions pas que le flux est entrée est décrypté et le flux en retour passe par le proxy aussi) ou tout simplement externe (ex: un utilisateur passe pas un proxy « anonymifiant » pirate ) Traefik préfère ne pas participer en disant à wordpress de créer des pages avec des liens HTTPS. Cela laisse le user-agent une chance de prévenir l’utilisateur que le serveur final (wordpress) n’a pas reçu la requête cryptée initialement.

Dans mon cas Traefik et le haproxy sont dans mon réseau interne et sont donc dignes de confiance. Je lance donc Traefik avec les options suivantes:

--entryPoints.web.address=:80 --entryPoints.web.forwardedHeaders.insecure

On peut améliorer la sécurité en indiquant à Traefik les IP sources des proxy auxquel il peut faire confiance.