Si j'utilise une connexion https sans certificat SSL valide, la connexion est-elle sécurisée? l'information est cryptée?
Je suis un peu confus à ce sujet = /
Merci!
Si j'utilise une connexion https sans certificat SSL valide, la connexion est-elle sécurisée? l'information est cryptée?
Je suis un peu confus à ce sujet = /
Merci!
La connexion est cryptée même si le certificat SSL n'est pas valide (expiré, huile de serpent, autorité de certification non approuvée, etc.). La validation du certificat SSL s'assure simplement que vous vous connectez aux personnes auxquelles vous pensez vous connecter. Le chiffrement ne vous est d'aucune utilité si les personnes qui déchiffrent vos données sont des pirates au lieu de PayPal.
En fait, il est possible d'établir une connexion chiffrée entre de parfaits inconnus sans un certificat, à l'aide de l'échange de clés Diffie-Hellman ou similaire algorithmes d'échange de clés.
Alice et Bob d'accord sur un nombre aléatoire x. Alice calcule xa, où a est un grand nombre premier connu seulement à Alice, et l'envoie à Bob. Bob calcule xbet il envoie à Alice. Alice calcule (xb)un, et Bob calcule (xa)b. Depuis (xa)b = (xb)un = xab, Alice et Bob maintenant à la fois de savoir le nombre xab et vous pouvez l'utiliser comme une clé de chiffrement. La beauté de ceci est que Bob ne sait pas un, Alice ne sait pas b, et tout les oreilles indiscrètes ne sais pas le nombre (puisque le calcul d' unede xun, dans le cas d'un grand nombre, faudrait des années).
Comme supercat points, ce par lui-même est encore sensible à un man-in-the-middle attack, et c'est pourquoi au moins une extrémité de la transaction a besoin de s'authentifier à l'aide d'un certificat. Pour être précis, cependant, il n'est pas le serveur qui vérifie cela, c'est le navigateur, et que la plupart des navigateurs permettent à l'utilisateur de continuer si le certificat n'est pas valide (ou peut-être même de déchets). Dans ce cas, la connexion sera toujours beaucoup plus sécurisé que d'une connexion normale. Écouter, vous devez être en mesure de manipuler le routage IP ou DNS recherches, et vous devez le configurer avant la connexion a été faite, ce qui n'est pas facile à faire.
BTW les paires de clés, des certificats sont pas ce qui est utilisé pour chiffrer le trafic réel; ils sont utilisés pour établir une nouvelle à usage unique clé pour une plus grande vitesse de chiffrement symétrique (comme DES) qui a ensuite fait le reste du travail.
Si il n'y avait pas de vérification de certificats SSL, puis quelqu'un qui a intercepté un canal de communication qui pourrait capturer une demande de connexion à https://www.acmebank.com, envoyer sa demande à www.acmebank.com et négocier avec les deux touches acmebank.com et l'utilisateur. Après cela, il pourrait recevoir chaque morceau de données de l'utilisateur, de déchiffrer avec la clé de l'utilisateur, et de crypter avec acmebank est la clé, et faire de même avec les données de acmebank.com. L'effet net serait de l'utilisateur, ni acmebank voudrais voir quelque chose de mal, mais l'intercepteur serait capable de déchiffrer toutes les données entre l'utilisateur et acmebank. L'utilisateur et la banque sera en utilisant différentes touches pour gérer leur communication, mais ni l'entité de les connaître. L'ajout de tout aspect standard pour le protocole pour demander ce que la clé est dans l'utilisation ne serait pas utile, puisque l'intercepteur peut détecter de telles requêtes et modifier les réponses de façon appropriée.
SSL empêche un man-in-the-middle attack en exigeant l'hôte d'envoyer au destinataire d'une copie de la clé de l'hôte utilise, cryptés dans un formulaire qu'un intrus ne pourra pas faux (à moins que l'intrus peut fausses informations d'identification CA, au moins). Si l'on n'utilise pas un CA-certificat émis, il y aura peu de protection à l'encontre d'un man-in-the-middle attaques, mais la cryptés la couche empêcherait passive ou rétrospective de déchiffrement de la session table des matières (BTW, je souhaite qu'il y ait des normes pour quelque chose entre la communication non chiffrée et SSL, pour les situations où passive ou rétrospective de déchiffrement sont la principale menace, mais je ne sais pas du tout).
Nan. Lorsque vous utilisez HTTPS, vous indiquez au navigateur de se connecter via un autre port (443) alors que normalement, vous vous connectez via (80). Sans certificat, le serveur refuserait la connexion. HTTPS n'est tout simplement pas possible sans certificat. Regardez ici et vous verrez qu'un certificat est nécessaire pour que cela fonctionne.
Oui, il est possible d’établir une connexion chiffrée, mais il est tout de même possible que vous communiquiez avec un ordinateur personnel craqué au lieu du serveur réel. Comme cela, l’ordinateur piraté dit au serveur qu’il serait le client, décrypterait toutes les données, les stockerait et enverrait les données cryptées au client (et lui dirait qu’il serait le serveur). Il ne s'agit donc que d'une connexion sécurisée s'il n'y a pas de point vulnérable entre le serveur et le client, ce que personne ne peut garantir.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.