Bonne pratique pour faire une redirection HTTP vers HTTPS ?

Bonjour,

Je dois mettre en place en serveur HTTP(S) qui gère des pages Web et une API RESTFull.

L'accès aux pages Web se fait via un formulaire qui permet de créer une session pour avoir accès au contenu des pages Web (ex: https://xxx/login > https://xxx/index).
Quand à l'API, l'authentification se fait par login/password via du "Basic Auth" (ex : https://xxx/api/yyy).

On me demande de gérer une redirection HTTP vers HTTPS, quelle est la bonne pratique pour faire ça ?

Quel devrait être la réponse du serveur pour les requêtes suivantes ?
- GET http://xxx/index.
- POST http://xxx/index.
- PATCH http://xxx/index.
- GET http://xxx/api/yyy.
- PATCH http://xxx/api/yyy.

Si un HTTP client lance une requête "PATCH http://xxx/api/yyy", la réponse doit être "302, location: https://xxx/api/yyy" ou "307, location: https://xxx/api/yyy" ou autre ?

Si un HTTP client lance une requête "POST http://xxx/index", la réponse doit être "302, location: https://xxx/login" ou "307, location: https://xxx/index" ou autre ?

Si l'URL est invalide (ex : un PATCH sur une URL qui n'existe pas), quelle doit être la réponse ?

Est-ce une bonne pratique de gérer le HTTP redirect pour une API ?... on me demande de faire ça mais je me demande si c'est vraiment utile : que devrait répondre le serveur en cas de requête en HTTP sur http://xxx/api ?
... en général, les API coté client savent de base gérer le HTTP redirect ?

Merci d'avance

le fait de ne pas utiliser https produit un risque pour la confidentialité des données transmises. donc en général, le passage par http au lieu de https n'est pas une des fonctionnalités du système mais une erreur d'utilisation.
donc, je pense qu'une simple réponse "attention vous n'utilisez pas https" suffit et qu'il n'y a pas besoin de chercher absolument une compatibilité ou une adaptation. en sachant que si la redirection se fait de manière transparente, il y a aura peut-être des clients qui continueront à passer par http étant que tout fonctionne.

tout cela est dans le cas général. peut-être que dans votre cas, l'utilisation de http sans https est considérée comme un fonctionnement habituel ?

Citation:

---

Envoyé par mathieu

tout cela est dans le cas général. peut-être que dans votre cas, l'utilisation de http sans https est considérée comme un fonctionnement habituel ?

---

Bonjour,

Le cas que je considère habituel est de rentrer l'url sans mettre le préfixe (http/https) et donc c'est mieux que si le client HTTP(S) se connecte par défaut en HTTP qu'il soit redirigé vers HTTPS... ça m'est demandé de le faire mais pas de précision sur la méthode.

Bonjour,

Le client ne doit pas pouvoir utiliser http si https est disponible, la connexion ne doit jamais utiliser http sinon les identifiants seront effectivement transmis en clair sur le réseau : il faut forcer l'utilisation du https.
Ceci est généralement configuré dans le serveur web : on ajoute une redirection permanente (301) de toutes les urls http vers les mêmes urls avec https.

Ca peut se faire en .htaccess sous Apache, mais sous Nginx ce sera différent, il n'y a pas d'équivalent direct.
Il faut voir de quel type de serveur vous disposez.

Mais vous faites bien de mentionner que c'est une API. Ce détail a son importance.
Il y a beaucoup de sites qui redirigent de http vers https, mais on n'est pas dans le même type d'interaction.

Si vous ouvrez le port 80 pour HTTP, ça veut dire que votre API accepte des données non chiffrées, et la redirection ne sert à rien, a priori elle arrive trop tard puisque le payload est déjà accepté et il a transité en clair sur le réseau. En plus, vous dites bien qu'il y a du Basic Auth. Raison de plus.
(Au passage, vous dites qu'il faut passer via un formulaire pour obtenir une session au préalable, pourquoi ne pas attribuer un token à durée limitée plutôt).

Mais en réalité la redirection ne marchera même pas, ça s'applique aux requêtes GET.
En fait, vous pourriez théoriquement utiliser le code HTTP/308 Permanent Redirect:

Citation:

---

The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method.

---

Mais il reste à voir comment le client va gérer la réponse, ou si même il l'implémente. Encore une fois, c'est une API, le client ne s'attend pas à une redirection et s'il ne suit pas délibérément les headers de redirection qui sont envoyés, la redirection ne se fait pas.

Donc ma recommandation est de fermer le port 80 et laisser seulement le port 443 exposé. On peut résoudre cela avec des règles firewall aussi.

Et si vous n'avez pas la main sur le serveur, alors refusez les appels en HTTP. Répondez avec une erreur qui est sémantiquement adaptée. Cela pourrait être HTTP/426 si on en croit les RFC: https://www.rfc-editor.org/rfc/rfc2817#section-4.2
Ce code n'est pas courant et peut être déconcertant, il faut donc l'accompagner d'un message clair comme le stipule la RFC par ailleurs.
Apparemment IIS renvoie une erreur 403, plus précisément un subset: 403.4 – SSL required dans ce cas de figure.

Pour résumer la demande qui vous est adressée est hors sujet dans votre cas de figure. Il ne faut pas chercher à la satisfaire.

Merci pour vos réponses