Pourquoi devrais-je proposer HTTP en plus de HTTPS?
J'installe un nouveau serveur Web. En plus de TLS/HTTPS, j'envisage d'implémenter Strict-Transport-Security et d'autres mécanismes d'application HTTPS.
Tout cela semble reposer sur l'hypothèse que je sers http://www.example.com en plus de https://www.example.com. Pourquoi ne sers-je pas uniquement HTTPS? Autrement dit, existe-t-il une raison de sécurité pour servir HTTP - par exemple, quelqu'un pourrait-il usurper http://www.example.com si je ne configure pas HSTS?
Pourquoi est-ce que je ne diffuse pas seulement https?
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. Voir 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 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 disposeront d'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 avec les anciens navigateurs vraiment.
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'homme au milieu?
Dans ce cas oui, mais même avec ou sans HSTS:
Sans HSTS : Un attaquant peut facilement être au milieu de votre serveur et de l'utilisateur, et être actif (ie, modifier le contenu) ou passif (ie , écoute indiscrète)
Avec HSTS : La première fois qu'un utilisateur essaie de visiter le site en utilisant HTTP, un attaquant pourrait forcer l'utilisateur à utiliser HTTP. Cependant, l'attaquant a une fenêtre de temps limitée quand il peut effectuer son attaque.
Ce que tu devrais 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 assurez-vous 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 selon votre base d'utilisateurs, cela ne devrait pas être un problème.
Conclusion
Désactiver HTTP fera plus de mal que de bien. Il 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 HTTP par défaut 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
Pour des raisons de convivialité, vous devez proposer une redirection vers HTTPS à partir de toutes les URL HTTP: s. Sinon, les nouveaux visiteurs qui entrent simplement example.com/some/page dans la barre d'URL du navigateur sera accueilli par une erreur de connexion.
Servir la redirection ne vous rend pas plus vulnérable. Les utilisateurs qui n'ont pas votre entrée HSTS dans leur navigateur feront de toute façon une demande HTTP. Qu'il y ait ou non un véritable service sur HTTP est sans importance pour un homme au milieu.
Vous devez donc exécuter un serveur HTTP, mais il n'a pas besoin de répondre avec autre chose que les redirections.
Les réponses votées sont très bonnes. Vous sacrifiez la convivialité sans impact majeur sur la sécurité si vous fermez complètement HTTP.
Cependant, vous pouvez atténuer cela avec l'option de préchargement HSTS. 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 HTTPS uniquement. 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/
Tu n'es pas obligé.
Certains navigateurs et systèmes d'exploitation plus anciens (qui 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 les normes HTTPS plus récentes, donc rien n'est vraiment perdu.
Vous pouvez avoir un appareil qui ne prend pas en charge HTTPS, script personnalisé, 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 devez prendre en charge HTTP uniquement pour prendre en charge la compatibilité descendante. Et assurez-vous que vous effectuez une redirection appropriée sur le serveur principal vers HTTPS. La meilleure façon de l'implémenter est de fournir la prise en charge 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 des 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 présentent 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 autorisez uniquement> TLS 1.1.
Il est bon que vous implémentiez le HSTS. Je vous recommande également d'examiner la faisabilité de l'implémentation de HPKP sur votre site.
J'utilise http en plus de https à deux fins:
- Faites la redirection http vers le site Web https. C'est pour si quelqu'un tape le nom de votre site dans le navigateur.
- 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 vrai utilisateur ne le fera pas.) Ce site Web affichera un simple message à venir. Il ajoutera également leur adresse IP à la liste de refus des tables IP pour bannir définitivement cette IP du serveur. Cette
s'arrêteralentit 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 de l'analyse Google, mais en fait, des pirates étrangers effectuant l'analyse IP à la recherche de serveurs Web pour essayer de pirater).