[IPLB NextGen] Redirection http vers https

Si c'est pour du http(s)
Le mieux serait de renvoyer un Header HSTS.
Ovh avait parlé à un moment de le faire (de mémoire).. Je ne sais pas si c'est inclus
Si le loadbalancer ne le fait pas tu peux le renvoyer pour tes sites.
Il faut ajouter ce code au htaccess sur tes serveurs
Pour l'activer sur tout un domaine ( tous les sous domaines compris)
`Header set Strict-Transport-Security "max-age=15811200; includeSubDomains; preload"`
Pour l'activer uniquement pour un sous domaine
`Header set Strict-Transport-Security "max-age=15811200"`

Bonjour et merci pour ta réponse.

Effectivement, je ne m'étais pas trop renseigné sur HSTS. De ce que j'ai pu voir, il y a bien une case permettant d'activer HSTS sur le frontend de l'IPLB. Par contre, pas possible de gérer l'option `includeSubDomains`.
Du coup, on est obligé de mettre ce header au niveau du serveur (nginx dans mon cas), mais cela m'oblige à maintenir le HTTPS côté serveur (et donc les certificats), ce qui n'était pas forcément le but.

Merci en tout cas pour ta suggestion qui fonctionne.

Paul

Bonjour,

Le HSTS est une fonctionnalité très différente, et souvent mal comprise. Dans l'idée, le HSTS est un entête HTTP envoyé en HTTPS *uniquement* qui indique au navigateur d'envoyer toutes ses futures requêtes en HTTPS uniquement pour une période de temps donnée. Vous pouvez le voir comme un "kill switch" pour de l'HTTP pour votre site.

D'un point de vue pratique, cette fonctionnalité a été pensée par les navigateurs pour se protéger contre une classe d'attaque particulièrement sournoise, les attaques par "downgrade". Le HTTPS étant virtuellement impossible à casser dans un délai raisonnable, les attaquants font croire au navigateur que le site ne gère pas le HTTPS et le force à basculer en clair afin de pouvoir l'espionner.

Si l'entête HSTS a bien été envoyée, le navigateur refusera de se connecter et l'attaque sera déjouée. Cette fonctionnalité ne doit être activée que si la configuration HTTPS a bien été éprouvée. Une fois activée, il n'y a plus de retour en arrière possible !

Pour le besoin initial de redirection, je vous fait une réponse un peu plus tard. La documentation est en cours d'écriture :slight_smile:

Du coup, on est obligé de mettre ce header au niveau du serveur (nginx dans mon cas), mais cela m'oblige à maintenir le HTTPS côté serveur (et donc les certificats), ce qui n'était pas forcément le but.

Non, ca doit fonctionner si le certificat est sur l IPLB puisque le navigateur envoie une requête https puis après le IPLB et ton serveur communique comme il veut. Le navigateur client ne voit que l IPLB lui. Donc si le certificat est dessus c'est bon.

Si tu veux tester tu peux mettre
Header set Strict-Transport-Security "max-age=200"
(ça ne force le https que pendant 200 secondes soit 3 minutes et 20 secondes)

Si l'entête HSTS a bien été envoyée, le navigateur refusera de se connecter et l'attaque sera déjouée. Cette fonctionnalité ne doit être activée que si la configuration HTTPS a bien été éprouvée. Une fois activée, il n'y a plus de retour en arrière possible !

Ça dépend le délai que l'on a mis...
Si l'on met un délai court pour tester le retour en arrière est facile..

Après une fois un site bascule et indexé en https même sans HSTS le retour en arrière est difficile car n'importe quelle personne passant par un moteur de recherche cliquera donc sur un lien https:// et aura une alerte sur le certificat absent....

Au sujet de la redirection, nous avons rajouté depuis quelques jours les "Routes" dans l'API IPLB. Nous ne l'avons pas encore annoncé car la documentation est encore en cours d'écriture. Avant de vous répondre, j'ai pris le temps de refaire un test pour m'assurer que tout fonctionne :slight_smile:

La première chose à faire, dans votre Manager Sunrise, c'est de bien noter
- le nom du produit (ip-a.b.c.d)
- le numéro du Frontend HTTP qui doit rediriger vers https://

Une fois ces informations identifiées, vous pouvez vous identifier dans la console de l'API OVH et vous rendre sur l'appel IP Load Balancer "POST http/route" https://api.ovh.com/console/#/ipLoadbalancing/%7BserviceName%7D/http/route#POST

Dans cet appel, vous devez renseigner les champs:
- ``serviceName``: Le nom de votre service de la forme **_ip-a.b.c.d_**
- ``frontendId``: Le numéro Frontend HTTP pour lequel vous souhaitez créer cette redirection
- ``action.type``: "_**redirect**_"
- ``action.target``: "**_https://${host}${path}${arguments}_**" (C'est la partie un peu magique :slight_smile: )
- ``action.status``: **_301_** pour une redirection permanente, **_302_** pour une redirection temporaire



Vous pouvez optionnellement préciser un ``displayName``. Il sert uniquement à l'affichage dans l'API et le Manager. Le champ ``weight`` indique une priorité. En l'occurence, il y a une seule route, donc pas besoin.

Vous pouvez optionnellement n'appliquer une route que si certaines conditions sont remplies. Ces conditions sont spécifiées en attachant des "rules" aux routes. Toutes les "rules" attachées à une route doivent être validées pour que la route soit prise en compte.

Vous pouvez à présent appliquer le configuration dans la zone de votre Frontend puis tester:

curl -svvv www.example.com/hello?name=world 2>&1 | grep "< Location:"
< Location: https://www.example.com/hello?name=world

Pour obtenir une liste des routes disponibles, vous pouvez consulter les calls d'API
- Routes: https://api.ovh.com/console/#/ipLoadbalancing/%7BserviceName%7D/availableRouteActions#GET
- Rules: https://api.ovh.com/console/#/ipLoadbalancing/%7BserviceName%7D/availableRouteRules#GET

Excellent.
ça répond parfaitement à mon problème.

ça semble assez puissant par ailleurs...