Vous ne devez pas fermer le port 80. Au lieu de cela, vous devez configurer votre serveur pour rediriger le port HTTP 80 vers le port HTTPS 443 afin d'utiliser TLS. Vous pouvez éventuellement utiliser HSTS (HTTP Strict Transport Security) pour dire aux navigateurs de se rappeler de n'utiliser TLS que lors de la connexion à votre site à l'avenir.
Il n'y a rien d'incertain à ce que le port 80 soit ouvert. Les problèmes de sécurité ne surviennent que lorsque le serveur Web traite des requêtes via une connexion non chiffrée, en particulier si ces requêtes contiennent des données sensibles. Avoir le port 80 ouvert et envoyer rien de plus qu'une redirection HTTP est parfaitement sûr.
Google, le principal moteur de recherche d'Internet (éclipsant à la fois Bing et Yahoo), et le navigateur utilisé par la majorité des internautes, a fait pression pour un monde HTTPS uniquement en diminuant le classement des pages pour les sites qui ne sont pas HTTPS, et en ajoutant un avertissement du navigateur lorsqu'un site n'est pas sécurisé. Cependant, le rapport entre les sites HTTPS et non est encore bien trop faible pour recommander une politique HTTPS d'abord pour tout le monde, car les utilisateurs recevraient assez constamment des messages effrayants "d'erreur de certificat" ou des erreurs de "connexion refusée".
Ainsi, jusqu'à ce que Google recommande une politique HTTPS d'abord pour les connexions de navigateur, il est peu probable que Firefox, Apple ou Microsoft recommandent de telles politiques non plus, et ce n'est probablement pas le cas avant une majorité décente (peut-être 70 % ou plus) des meilleurs sites. sont compatibles HTTPS, ce qui représenterait une énorme augmentation par rapport aux ~50 % des meilleurs sites qui ont HTTPS aujourd'hui.
La plupart des utilisateurs qui visitent intentionnellement ou accidentellement votre site HTTP, s'ils sont accueillis par une erreur "connexion refusée", passeront probablement à un autre site. Je n'ai pas de bon moyen d'obtenir des chiffres concrets ici, mais il est probable que 70 à 90 % des internautes ne comprendraient probablement pas que le site n'a pas de port HTTP sans une redirection automatique ; les autres sont probablement suffisamment compétents techniquement pour se rendre compte qu'ils ont besoin de HTTPS, ou utilisent HTTPS Everywhere, et ne le remarqueraient pas de toute façon.
Utilisez certainement HSTS, certainement la redirection 301 vers les ressources HTTPS (le 301 indique un passage permanent aux navigateurs, donc ils "se souviendront" de cette préférence), conseillez certainement à vos utilisateurs de s'assurer qu'ils voient un cadenas et de vérifier le certificat, etc. bloquer le port 80 à ce stade, car Internet n'est tout simplement pas encore prêt pour cela.
Autant que je sache, aucun site majeur n'a désactivé HTTP et port bloqué 80. Si vous faites cela, vous briserez les attentes des utilisateurs (que le site vous redirigera vers un site sécurisé), et comme la plupart des utilisateurs ne sauront pas quoi faire ici, car ils n'obtiendront pas un message d'erreur, supposera simplement que votre site est cassé et passera à autre chose.
En bref :EN GÉNÉRAL, gardez-le ouvert et utilisez-le pour rediriger tout à HTTPS.
Passons maintenant aux trucs compliqués :la suppression du port 80 peut arrêter les voleurs de cookies qui recherchent passivement le straggle http://corp.com/some/forgotten/thing demandes. La connexion TCP échoue, le navigateur n'envoie pas le GET et les cookies, et le méchant ne peut pas les lire.
Parfois, il est raisonnable de se protéger contre cela, en particulier en pensant aux environnements d'entreprise :applications héritées, HSTS seulement partiellement mis en œuvre, cookies qui peuvent ne pas avoir l'indicateur ou le chemin sécurisé ou les restrictions d'hôte, tiers hébergés ou mandatés, ...
Maintenant, devriez-vous vous bloque le? Probablement pas.
Comme d'autres l'ont mentionné, cela compliquerait la configuration de Let's Encrypt et empêcherait les redirections (y compris les utilisateurs qui tapent simplement your.com dans la barre d'adresse). Si vous avez défini un HSTS à l'échelle du domaine, la suppression des redirections peut même être considérée comme contre-productive (vous voudrez peut-être en risquer une connexion HTTP simple afin de protéger tous futurs).
Notez également que les attaquants actifs ne seront pas arrêtés (ils peuvent établir la connexion artificiellement, les outils de proxy MITM peuvent même le faire par défaut), il existe des cas particuliers (proxy HTTP simples, domaines délégués en dehors de votre pare-feu), et vous pouvez simplement considérez l'attaque passive trop compliquée pour votre modèle.
Enfin, devriez-vous ajouter port 80 vers un nouveau serveur ? Eh bien, à moins que vous n'ayez déjà une raison de l'ouvrir (voir ci-dessus), non.