Les données envoyées du serveur Web au navigateur sont-elles vraiment plus sécurisées en https qu'en http?


-2

Je viens de lire sur les différences entre http et https brièvement. Et ce que je n'ai pas compris, c'est le scénario possible suivant:

Tout le monde a la clé publique SSL, non?

Ainsi, n'importe qui peut obtenir la clé publique d'un serveur Web, puis l'utiliser pour déchiffrer les messages envoyés depuis le serveur Web? De cette façon, si le serveur Web envoie des informations secrètes, les intrus peuvent le savoir, non?

J'ai compris que la clé privée appartient au serveur Web. Par conséquent, seul le serveur Web peut déchiffrer le message crypté (à l'aide d'une clé publique) envoyé par le navigateur. Les données envoyées par le navigateur sont donc sécurisées. Mais je doute que les données reçues du serveur Web soient réellement sécurisées.

Ou disons si la clé publique change d'un utilisateur à l'autre. Mais l'intrus peut le pirater lorsque le navigateur l'envoie pour la première fois, n'est-ce pas?

S'il vous plaît corrigez-moi si j'ai mal compris.

EDIT: D'accord, je pense que je l'obtiens de la description fournie par le questionneur dans ce lien:

Comment fonctionne SSL? N'y a-t-il pas un trou?

Ça dit:

Lorsque le client se connecte à company.com sur son port sécurisé SSL, l'entreprise renvoie sa clé publique (ainsi que d'autres informations, telles que le type de cryptage pris en charge). ... une fois que le client est satisfait du serveur (et le serveur avec le client, si nécessaire), le client choisit un chiffrement SSL à utiliser dans la liste des méthodes de chiffrement fournies par le serveur, et génère une "clé symétrique" (mot de passe) à utiliser avec ce chiffre. Le client chiffre ce mot de passe à l'aide de la clé publique du serveur et le renvoie au serveur. Le serveur (et seul le serveur) peut déchiffrer ce message et obtenir ce mot de passe, qui est maintenant partagé par le client et le serveur.

Cela signifie que le client ne crypte pas uniquement avec la clé publique qu'il possède, mais utilise un mot de passe qu'il a généré (clé symétrique) qui sera partagé avec le serveur Web à l'aide du cryptage à clé publique. Et seul le serveur Web peut connaître le mot de passe partagé par le client, car il est seul propriétaire de la partie clé privée. Le serveur Web et le client utilisent donc la clé symétrique pour chiffrer les messages, ce que personne ne sait ni ne peut s’immiscer.

Ai-je raison?


1
Trop de questions dans un post.
Moab

@moab c'est juste une seule question
GP92

1
Je vois 8 points d’interrogation (y compris le titre), ce n’est pas une question unique.
Moab

@ Moab Avez-vous lu la question ... ces points d'interrogation ne sont qu'une expression ... mais ma question n'en est qu'une.
GP92

En désaccord, ce sont des questions qui pourraient avoir des réponses possibles.
Moab

Réponses:


0

Je pense que vous avez une meilleure idée, mais pensez-y de cette façon. Le chiffrement a tendance à utiliser une clé publique et une clé privée, les deux servent à la déverrouiller et le seul qui soit connu est la clé publique. Comme la clé privée a tendance à être stockée avec le certificat SSL, personne ne connaît la clé utilisée pour déchiffrer les messages. Cela sécurise les messages dans les deux sens, et à moins d'utiliser une vulnérabilité, il est impossible pour quelqu'un de dire ce qui est envoyé dans les deux sens. Les vulnérabilités impliquent généralement des logiciels malveillants ou un faux certificat SSL, mais vous pouvez les rechercher sur Google pour en savoir plus sur ce type de problème.

Ce que je pense que vous devriez également savoir, c’est que le chiffrement n’est pas une preuve absolue, et peut être rompu en fonction de la force de la clé. Un bon exemple est le SuperFish (je pense que c'est le bon nom) dans lequel Lenovo était impliqué il y a quelques mois. Ils utilisaient un certificat SSL qui remplacerait le certificat pour d'autres sites Web. Cela signifie simplement qu'il utilisait son certificat SSL pour un accès sécurisé à divers sites, mais le problème était que la clé privée avait un mot de passe facile à deviner. Ils n'ont pas eu à casser l'algorithme, car la société a utilisé le nom de la société pour le mot de passe (komodia). Désormais, tous les ordinateurs utilisant ces certificats Superfish n'étaient plus sécurisés, car tout le monde pouvait déchiffrer les messages et voir quelles informations étaient échangées. Le seul obstacle serait d’avoir accès au trafic, mais ça

Ce n'est pas courant, mais la plupart des sites utilisent des clés puissantes qui peuvent mettre des dizaines, voire des centaines d'années avant d'être cassées (sans le mot de passe). Si vous voulez savoir ce qui rend les certificats forts ou non, vous pouvez également le rechercher sur Google. Est-ce que cela dissipe toute autre confusion?


Merci. La dernière fois que j'ai lu sur le superfish de Lenovo, je ne savais pas ce que je lisais.
GP92

Je ne pense pas que la clé privée Superfish était faible; c'était simplement que sa phrase secrète était incluse dans le malware installé sur les ordinateurs Lenovo. Ce mot de passe était nécessaire pour créer de faux certificats quel que soit le site Web visité, permettant ainsi à Superfish d'injecter des publicités dans ces pages.
Arjan

Pensez-y de cette façon, le mot de passe de la clé privée est le nom de la société qui utilisait Superfish, ce qui était un mot de passe assez facile à deviner (il n'a pas fallu longtemps pour que les gens le découvrent). C'est la même chose que de laisser la clé d'une porte imprenable, sous le tapis de porte. Cela le rend faible / facile à pénétrer. Je ne dis pas que l'algorithme utilisé était faible, mais l'un ou l'autre peut rendre une clé privée faible (algorithme ou mot de passe).
dakre18

... "la clé privée était faible et quand elle était cassée, elle utilisait un mot de passe facile à deviner" suggère le contraire, à mon avis. Cela dit, je pense que le principal problème était de distribuer la clé privée et sa phrase secrète (en plus de l'installation de leur propre certificat racine dans le système d'exploitation) ...
Arjan

Certes, je pourrais corriger le libellé, mais la distribution n’est pas un problème si le mot de passe est facile à deviner. Les gens ont la mauvaise habitude d’être paresseux avec les mots de passe, ils utilisent donc quelque chose de facile à retenir qui leur est familier (consultez le top 10 des mots de passe Ashley Madison). Dans ce cas, peu importe le nombre de personnes qui l'ont distribué, car ils l'ont trouvé en devinant au lieu de casser l'algorithme. Si les journalistes et les experts en sécurité peuvent deviner le mot de passe, les personnes mal intentionnées le devineront facilement (qui le fait pour gagner sa vie).
dakre18

0

HTTPS est la version supérieure de HTTP, créée spécialement pour les transactions sécurisées entre le client et le serveur. Cette connexion fonctionne sur les protocoles de communication SSL ou TLS et les deux protocoles utilisent un Asymmetricsystème d'infrastructure à clé publique. Un système asymétrique utilise deux clés (publique / privée) pour chiffrer / déchiffrer des données. Lorsqu'une demande de client pour une page vers un serveur envoie deux éléments avec Response to le client - une clé publique et un certificat, chaque fois que la communication est établie sur ce canal, le cryptage / décryptage des données à l'aide de la clé privée et du navigateur a été effectué. sa clé publique pour chiffrer / déchiffrer des données.

Vous avez une question qui est-il possible de pirater ces clés?

À mon avis, c'est possible.

À l'heure actuelle, il existe de nombreux algorithmes pour chiffrer et déchiffrer des données / clés. Par exemple, prenons un algorithme SHAcomportant de nombreuses versions et s’améliorant jour après jour. Pour plus d'informations sur la SHA3visite de ce lien. Donc, si Intruder pirate la clé publique mais qu’il n’est pas possible de la déchiffrer par eux sans SHA keyutiliser la clé déchiffrée. (Qu'est-ce que j'ai appris de Google), car SHA-3 24 tours de cryptage sur une donnée avec une clé. Quelque part j'avais lu que SHA-3est plus puissant que les autres algorithmes. Donc, si des intrus ont une clé publique sous la main qu'ils ne peuvent pas déchiffrer directement leurs données, ils ont besoin d'une autre clé avec laquelle ces clés (publique / privée) sont cryptées. Les données sont cryptées par les clés et les clés sont également cryptées par une autre clé qui n'est partagée sur aucune plate-forme, qu'il s'agisse du client ou du serveur. Si des modifications sont apportées à ces clés, elles seront également identifiées par le serveur et pour les données. Parce que certains comment il génère un code de hachage à l'aide duquel il peut être identifié. Voyez comment SHA fonctionne, Mécanisme d'algorithme de hachage sécurisé

HTTPS est la connexion la plus sécurisée jusqu’à ce jour et chaque site requis pour une transaction sécurisée utilise la connexion HTTPS uniquement entre les clients et le serveur.

En conclusion, si la clé n'est pas protégée par l'intrus, cet algorithme peut identifier les changements dans les données. C’est pourquoi il est possible de réaliser des connexions sécurisées.

J'espère que cela vous aidera à comprendre ce qui se passe exactement derrière cette scène.

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.