Activation de HSTS dans l'équilibreur de charge d'application AWS ELB
Nous aimons activer HSTS dans notre application Web déployée IIS.
Nous avons un équilibreur de charge d'application ELB SSL. Nous avons activé le module de réécriture d'URL dans IIS et configuré la balise x-Forward-Proto pour décider et activer l'en-tête HSTS dans la réponse.
Actuellement, ALB ne semble pas transmettre les en-têtes personnalisés de IIS à l'ALB, à l'utilisateur final. Nous voulions voir s'il y avait un moyen d'activer HSTS soit au niveau ALB où il peut accepter les en-têtes personnalisés ou s'il peut être défini à IIS level et ALB peuvent passer par les en-têtes HSTS vers le navigateur?
HSTS est une stratégie qui est contrôlée par le backend et non par l'équilibreur de charge. On pourrait soutenir qu'AWS pourrait permettre cela, mais il y a d'autres problèmes qui rendent cela plus compliqué (violation des spécifications, redirections permanentes pour HTTP, etc.)
Le problème avec HSTS est que vous ne pouvez pas (ne devez pas) envoyer Strict-Transport-Security sur HTTP. Les spécifications disent d'envoyer uniquement l'en-tête via une connexion sécurisée. HTTP n'est pas sécurisé. Étant donné que l'équilibreur de charge parle au backend via HTTP, IIS n'envoie PAS l'en-tête. Vous devez utiliser HTTPS sur le backend pour activer HSTS.
Si votre objectif est d'envoyer "Strict-Transport-Security" au client, utilisez des écouteurs de couche 4 sur votre équilibreur de charge et gérez HTTPS sur votre serveur principal. Si une demande arrive sur HTTP, envoyez une redirection permanente (301). Les avantages incluent un contrôle absolu, HTTP/2 amélioré, etc.
Une autre option consiste à changer votre écouteur pour utiliser HTTPS pour parler au backend. Configurez HTTPS et SSL sur le backend.
Il semble que ce soit l'approche utilisée par l'OP, mais pour une raison quelconque, les en-têtes n'ont pas été transmis. Je veux juste confirmer que cette approche fonctionne vraiment et donner des détails supplémentaires.
Il est tout à fait possible de définir l'en-tête HSTS sur un serveur principal via HTTP. À la fin de la journée, ce n'est qu'un en-tête comme les autres et le serveur sera ravi de l'envoyer.
Cependant, ce qui se passe, c'est que le NAVIGATEUR ignorera l'en-tête HSTS reçu sur une réponse HTTP, conformément à la spécification HSTS.
MAIS, il existe un moyen de le faire fonctionner, tout d'abord vous configurez votre serveur principal pour envoyer l'en-tête HSTS.
Ensuite, en supposant que l'Application Load Balancer écoute sur HTTPS, mais que votre groupe cible (et les serveurs principaux) sont sur HTTP, ce qui se passe est:
- le navigateur envoie une demande à ALB via HTTPS
- ALB transmet la demande de backend via HTTP
- le serveur principal envoie la réponse, y compris l'en-tête HSTS, à l'ALB via HTTP
- ALB envoie la même réponse + en-tête au navigateur via HTTPS .
Par conséquent, le navigateur reçoit la réponse et l'en-tête HSTS via HTTPS, et il obéira à HSTS.
Un argument contre cela est que vous ne devez pas envoyer d'en-tête HSTS sur HTTP. Cependant, le même argument s'applique à l'ensemble de votre site Web - personne ne devrait servir des sites Web via HTTP à Internet. Si vous considérez qu'il est sûr de terminer HTTPS sur l'ALB et d'exécuter le serveur principal sur HTTP, il est tout aussi sûr d'envoyer l'en-tête HSTS de la même manière.
REMARQUE: si vous utilisez HSTS, vous avez presque certainement une redirection HTTP vers HTTPS en place. Gardez à l'esprit que l'en-tête HSTS sera envoyé avec la redirection sur HTTP, mais le navigateur l'ignorera. Une fois que la redirection se produit et que l'en-tête HSTS arrive sur HTTPS, le navigateur y obéit.
Techniquement selon RFC6707 section 7.2 , vous ne devez pas renvoyer l'en-tête HSTS au navigateur via HTTP simple. Ce que vous devez faire est de conditionner le réglage de l'en-tête, basé sur X-Forwarded-Proto demande la valeur d'en-tête.