Pour des raisons de convivialité, vous devez proposer une redirection vers HTTPS à partir de toutes les URL HTTP: s. Sinon, les visiteurs pour la première fois qui saisissent simplement example.com/some/page dans la barre d'URL du navigateur seront accueillis par une erreur de connexion.

La diffusion de la redirection ne vous rend pas plus vulnérable. Les utilisateurs qui n'ont pas votre entrée HSTS dans leurs navigateurs feront quand même une requête HTTP. Qu'il y ait un vrai service ou non sur HTTP n'a pas d'importance pour un homme du milieu.

Vous devez donc exécuter un serveur HTTP, mais il n'a pas besoin de répondre avec autre chose que les redirections .

Pourquoi est-ce que je ne sers que https uniquement?

Les principales raisons sont le comportement par défaut des navigateurs et la compatibilité descendante .

Comportement par défaut

Lorsqu'un utilisateur final (c'est-à-dire, sans connaissance des protocoles ou de la sécurité) tape l'adresse du site Web dans son navigateur, le navigateur utilise par défaut HTTP. Consultez cette question pour plus d'informations sur les raisons pour lesquelles les navigateurs choisissent ce comportement.

Ainsi, il est probable que les utilisateurs ne pourront pas accéder à votre site Web.

Rétrocompatibilité

Il est possible que certains utilisateurs avec d'anciens systèmes et d'anciens navigateurs ne prennent pas en charge HTTPS ou, plus probablement, ne disposent pas d'une base de données à jour de certificats racine , ou ne prennent pas en charge certains protocoles.

Dans ce cas, ils ne pourront pas accéder au site Web ou recevront un avertissement de sécurité. Vous devez définir si la sécurité de vos utilisateurs finaux est suffisamment importante pour forcer HTTPS.

De nombreux sites Web écoutent toujours HTTP mais redirigent automatiquement vers HTTPS et ignorent les utilisateurs vraiment anciens navigateurs.

Quelqu'un pourrait-il usurper http://www.example.com si je ne configure pas HSTS?

Si un attaquant veut usurper http://www.example.com , il doit prendre le contrôle du domaine ou prendre le contrôle de l'adresse IP d'une manière ou d'une autre.

Je suppose que vous vouliez dire: un attaquant pourrait-il effectuer une attaque d'intermédiaire?

Dans ce cas oui, mais même avec ou sans HSTS:

• Sans HSTS : un attaquant peut facilement se trouver au milieu de votre serveur et de l'utilisateur, et être actif (c.-à-d. modifier le contenu) ou passif (c.-à-d. espionner)

• Avec HSTS : la première fois qu'un utilisateur tente de visiter le site via HTTP, un attaquant peut forcer l'utilisateur à utiliser HTTP. Cependant, l'attaquant dispose d'une fenêtre de temps limitée pour effectuer son attaque.

Que devez-vous faire?

Comme de nombreux sites Web, vous devez autoriser les connexions HTTP et faire en sorte que votre serveur redirige l'utilisateur vers la version HTTPS. De cette façon, vous remplacez le comportement par défaut des navigateurs et vous assurez que vos utilisateurs utilisent la version HTTPS.

Les anciens systèmes sans les protocoles ou certificats racine appropriés ne pourront pas accéder au site (ou du moins auront un avertissement ), mais en fonction de votre base d'utilisateurs, cela ne devrait pas être un problème.

Conclusion

Cela fera plus de mal que de bien de désactiver HTTP. Cela n'offre pas vraiment plus de sécurité.

Toute sécurité ajoutée pour protéger une ressource est inutile si elle empêche la plupart de ses utilisateurs d'y accéder. Si vos utilisateurs finaux ne peuvent pas accéder à votre site Web parce que leur navigateur utilise par défaut HTTP et que vous n'écoutez pas les connexions HTTP, quel est l'avantage?

Effectuez simplement la redirection HTTP 301 vers la version HTTPS.

Questions connexes

• Pourquoi les navigateurs utilisent-ils par défaut http: et non https: pour les URL saisies?
• Pourquoi HTTPS n'est-il pas le protocole par défaut?
• Pourquoi ne devrait-on pas utiliser SSL?
• Pourquoi certains sites Web imposent-ils l'absence de SSL ?

Les réponses à la hausse sont très bonnes. Vous sacrifierez la convivialité sans impact majeur sur la sécurité si vous désactivez complètement HTTP.

Cependant, vous pouvez atténuer cela avec l'option HSTS Preload. Le préchargement de votre site Web signifie que vous enregistrez votre domaine auprès des fournisseurs de navigateurs et qu'ils coderont en dur leurs navigateurs pour visiter votre site Web via HTTPS uniquement. Cela signifie que si un utilisateur tente d'accéder à votre site Web via HTTP, le navigateur changera la demande en HTTPS. L'utilisateur n'a pas besoin d'obtenir d'abord l'en-tête HSTS avant d'être sécurisé. Ils se connecteront toujours à vous via un canal sécurisé.

Maintenant, cela ne protège pas les utilisateurs qui utilisent des navigateurs qui n'ont pas mis à jour leur liste de sites Web uniquement HTTPS. Même lorsque vous utilisez le préchargement, je recommande de ne pas désactiver HTTP pour les quelques personnes qui utilisent des navigateurs anciens ou non mis à jour.

Mais attention, le préchargement est permanent! Il est extrêmement difficile de sortir de la liste de préchargement.

Pour accéder à la liste de préchargement: https://hstspreload.org/

Vous n'êtes pas obligé de le faire.

Certains navigateurs et systèmes d'exploitation plus anciens (ceux-ci vont généralement de pair) n'ont pas d'autorités racine de certificat plus récentes, mais ils ne prennent généralement pas en charge HTTPS plus récent non plus, donc rien n'est vraiment perdu.

Vous pouvez avoir un appareil qui ne prend pas en charge HTTPS, les scripts personnalisés, etc.

Personne ne peut usurper HTTP, car l'enregistrement DNS vous appartient et l'enregistrement A pointe vers votre adresse IP spécifique (dans un monde parfait).

Vous le faites juste pour maintenir la compatibilité, c'est tout.

Vous ne devez prendre en charge HTTP que pour prendre en charge la rétrocompatibilité. Et assurez-vous que vous effectuez une redirection correcte du serveur principal vers HTTPS. La meilleure façon de l'implémenter est de fournir le support HTTP uniquement à votre page d'accueil ou à toute page qui ne contient pas d'informations sensibles. Vous ne devez pas prendre en charge les requêtes HTTP vers les pages auxquelles l'utilisateur peut accéder après l'authentification.

Même si des appareils (IoT) accèdent aux données sensibles de votre serveur, vous devez les forcer à utiliser TLS (de nombreux appareils actuels peuvent stocker votre certificat et créer une connexion TLS). Gardez à l'esprit que les versions SSL antérieures à 3.0 comportent de nombreuses vulnérabilités telles que poodlebug etc. Par conséquent, désactivez toutes les versions précédentes de votre serveur Web et n'autorisez que> TLS 1.1.

Il est bon que vous implémentiez le HSTS. Je vous recommande d’examiner également la faisabilité de l’implémentation de HPKP sur votre site.

J'utilise http en plus de https à deux fins:

1. Effectuez la redirection http vers le site Web https. C'est pour si quelqu'un tape le nom de votre site dans le navigateur.
2. Je crée un site Web distinct pour http qui est destiné si quelqu'un essaie d'accéder au site Web sans utiliser le nom dot com. (Un utilisateur réel ne le fera pas.) Ce site Web affichera un simple message Coming Soon. Il ajoutera également leur adresse IP à la liste de refus des tables IP pour interdire définitivement cette adresse IP du serveur. Cette arrête ralentit les pirates qui utilisent masscan. (J'ai trouvé masscan en stockant les chaînes d'agent utilisateur de toutes les adresses IP que je bloquais pour prouver à un autre programmeur qu'il ne s'agissait pas d'une analyse Google, mais en fait, des pirates étrangers effectuant l'analyse IP à la recherche de serveurs Web à essayer de pirater).