HTTP sur le port 443 vs HTTPS sur le port 80


21

Quelle est la différence entre

http://serverfault.com:443 et /server/:80

Lequel est le plus sûr en théorie?


3
Le protocole HTTPS sur le port 80 peut se produire, mais uniquement dans le cadre d'une communication de serveur à serveur, les navigateurs ne le prennent pas en charge. La sécurité ne concerne pas le port, il s'agit d'un protocole.
Anatoly

4
Les navigateurs @Anatoly prennent en charge HTTPS sur le port 80, c'est juste qu'ils ne le sont pas par défaut. Le port par défaut pour HTTPS dans les navigateurs est 443, mais vous pouvez le remplacer dans pratiquement tous les navigateurs. Je pense que c'est ce que vous vouliez dire, mais je voulais clarifier pour quelqu'un d'autre.
Hurricane Development

@HurricaneDevelopment mon commentaire était essentiellement ce que les ingénieurs principaux de Nginx ont dit sur le forum Nginx à l'époque, je ne sais pas comment les choses ont changé au fil du temps.
Anatoly

@Anatoly Fari assez, juste en ajoutant plus d'informations.
Développement d'ouragans

Réponses:


26

http et https font référence au protocole utilisé.

http est utilisé pour la communication en clair en clair, ce qui signifie que les données transférées peuvent être interceptées et lues en clair par un être humain. Les champs de nom d'utilisateur / mot de passe peuvent par exemple être capturés et lus.

https fait référence à la communication cryptée SSL / TLS. Il doit être décrypté pour être lu. Normalement / idéalement, seuls les points d'extrémité sont capables de crypter / décrypter les données, bien qu'il s'agisse d'une déclaration avec des mises en garde ( voir la modification ci-dessous ).

Par conséquent, https peut être considéré comme plus sécurisé que http.

: 80 et: 443 se réfèrent uniquement au port du serveur utilisé (c'est-à-dire que c'est "juste un numéro") et n'a aucune signification en termes de sécurité.

Cependant, il existe une forte convention pour envoyer http sur le port 80 et https sur le port 443, ce qui rend les combinaisons dans la question plus que peu orthodoxes. Ils sont techniquement parfaitement utilisables cependant, tant que les points de terminaison sont en accord et pas d'objets de filtrage intermédiaires.

Donc, pour répondre, http://example.com:443 est moins sécurisé que https://example.com:80 et la différence est pratique (même si elle peut être compensée de plusieurs façons) et pas seulement théorique.

Vous pouvez facilement tester la validité de ces instructions à l'aide d'un serveur Web et d'un client où vous manipulez le port du serveur et l'état de chiffrement, tout en capturant et en comparant chaque session avec un décodeur de protocole tel que Wireshark.

[ EDIT - mises en garde concernant la sécurité du chemin client / serveur ]

Ce qui équivaut essentiellement à une attaque man-in-the-middle https peut être effectué à des fins d'écoute ou d'emprunt d'identité. Cela peut être fait comme un acte de malveillance, de bienveillance ou comme il s'avère même en raison de l'ignorance, selon les circonstances.

L'attaque peut être effectuée soit en exploitant une faiblesse de protocole telle que le bug heartbleed ou la vulnérabilité Poodle , soit en instanciant un proxy https entre le client et le serveur dans le chemin réseau ou directement sur le client .

Je pense que l'utilisation malveillante n'a pas besoin de beaucoup d'explications. Une utilisation bienveillante serait par exemple une organisation mandatant des connexions https entrantes à des fins de journalisation / identifiants , ou des connexions https sortantes pour filtrer des applications autorisées / refusées . Un exemple d'utilisation ignorante serait l'exemple Lenovo Superfish lié ci-dessus ou la récente variation Dell du même dérapage.

EDIT 2

Avez-vous déjà remarqué comment le monde fait que les surprises arrivent? Un scandale vient d'éclater en Suède, où trois organisations de santé des conseils de comté ont utilisé la même chaîne d'approvisionnement pour enregistrer les événements liés aux soins de santé par le biais des appels téléphoniques des patients.

Pour ainsi dire, la question obtient ainsi une réponse à grande échelle. Si seulement c'était une plaisanterie pratique et non un événement réel ...

Je vais simplement coller deux extraits traduits du texte des actualités dans Computer Sweden :

”Computer Sweden peut aujourd'hui révéler l'une des plus grandes catastrophes jamais enregistrées en matière de sécurité des patients et d'intégrité personnelle. Sur un serveur Web ouvert sans aucune forme de protection par mot de passe ou autre méthode de sécurité, nous avons trouvé 2,7 millions d'appels enregistrés de patients vers les soins de santé via le numéro d'avis médical 1177. Les appels remontent à 2013 et contiennent 170 000 heures de voix sensible appeler des fichiers que n'importe qui pourrait télécharger et écouter.

[...]

Les appels ont été enregistrés sur le serveur de stockage Voice Integrated Nordics à l'adresse IP http://188.92.248.19:443/medicall/ . Le port TCP 443 indique que le trafic a été transmis via https, mais la session n'est pas chiffrée.

Je ne peux pas décider si c'est encore un autre exemple d'ignorance, ou si nous voyons une catégorie entièrement nouvelle. Veuillez conseiller.


Que vouliez-vous dire en disant que cette déclaration sur le chiffrement / déchiffrement des données comporte des réserves? Veuillez expliquer
Oleg

@Curious J'ai modifié ma réponse pour réfléchir à votre question.
ErikE

1
Merci @ErikE. Il y a quelques jours, j'ai remarqué que la plupart des sites https que je visite (à l'exception des sites avec EV SSL) sont vérifiés par avast! Web/Mail Shield Root(j'utilise l'antivirus Avast), ce qui m'a un peu dérouté. Maintenant, tout est clair, grâce à vous
Oleg

1
éventuellement avast utilise ses propres certificats pour décrypter le trafic SSL. Selon votre configuration de sécurité, cela pourrait être un problème pour vous. Voir fe blog.avast.com/tag/man-in-the-middle
Dennis Nolte
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.