Comment est-il possible que les personnes observant une connexion HTTPS en cours d'établissement ne sachent pas comment la déchiffrer?

Thomas Pornin

2011-08-16 00:35:59 UTC

view on stackexchange narkive permalink

C'est la magie de la cryptographie à clé publique. Les mathématiques sont impliquées.

Le schéma d'échange de clés asymétrique qui est le plus simple à comprendre est le cryptage asymétrique avec RSA. Voici une description simplifiée à l'extrême:

Soit n un grand entier (disons 300 chiffres); n est choisi tel qu'il soit un produit de deux nombres premiers de tailles similaires (appelons-les p et q ). On va alors calculer les choses "modulo n ": cela signifie que chaque fois qu'on additionne ou multiplie deux entiers, on divise le résultat par n et on garde le reste (qui est entre 0 et n-1 , nécessairement).

Étant donné x , calculer x ³ modulo n est simple: vous multipliez x par x puis à nouveau par x , puis vous divisez par n et gardez le reste. Tout le monde peut le faire. En revanche, étant donné x³ modulo n , récupérer x paraît trop difficile (les méthodes les plus connues étant beaucoup trop cher pour la technologie existante) - à moins que vous connaissiez p et q , auquel cas cela redevient facile. Mais calculer p et q à partir de n semble également difficile (c'est le problème connu sous le nom de factorisation d'entiers).

Voici donc ce que font le serveur et le client:

Le serveur a un n et connaît le p em correspondant > et q (il les a générés). Le serveur envoie n au client.
Le client choisit un x aléatoire et calcule x ³ modulo n.
Le client envoie x³ modulo n au serveur.
Le serveur utilise sa connaissance de p et q pour récupérer x .

À ce stade, le client et le serveur connaissent x . Mais un espion n'a vu que n et x³ modulo n ; il ne peut pas recalculer p , q et / ou x à partir de ces informations. Donc x est un secret partagé entre le client et le serveur. Après cela, il s'agit d'un cryptage symétrique assez simple, utilisant x comme clé.

Le certificat est un conteneur pour la clé publique du serveur ( n ). Il est utilisé pour contrecarrer les attaquants actifs qui voudraient se faire passer pour le serveur: un tel attaquant intercepte la communication et envoie sa valeur n à la place du n du serveur. Le certificat est signé par une autorité de certification, afin que le client sache qu’un n donné est vraiment le n authentique du serveur qu’il souhaite parler avec. Les signatures numériques utilisent également la cryptographie asymétrique, bien que de manière distincte (par exemple, il existe également une variante de RSA pour les signatures numériques).

J'aime vraiment cette réponse. Est-ce techniquement exact en ce qui concerne SSL? Si c'est le cas, je suis tenté de le marquer comme «le plus utile». La réponse de Gowenfawr est également très utile et a beaucoup plus de votes, mais comme elle a "des détails mutilés", je me demande si cette réponse est plus précise.

J'ai sauté beaucoup de détails, par exemple l'exposant "3" peut être une autre valeur (traditionnellement 65537) qui est considérée comme faisant partie de la clé publique. De plus, il y a un remplissage à un moment donné (la valeur aléatoire que le client choisit est inférieure à _x_; _x_ résulte de l'application d'une transformation relativement simple). En dehors de cela, c'est ainsi que cela se passe dans la plupart des connexions SSL (l'algorithme d'échange de clés est négocié au début, mais dans la plupart des serveurs et clients SSL déployés, cela se termine par RSA, comme je le décris, et non Diffie-Hellman).

Un petit ajustement - dans SSL / TLS - le X de cette explication est en fait le "pré-secret principal", il est utilisé à la fois par le client et le serveur pour générer le "secret principal". Ensuite, un autre calcul est effectué pour créer le "bloc clé" qui est une manière de générer suffisamment de sortie basée sur le secret principal et une série d'entrées aléatoires pour créer la clé symétrique nécessaire pour le chiffrement symétrique sélectionné. C'est vraiment un petit morceau car il est assez linéaire - si un attaquant avait le secret pré-maître et les messages de bonjour clairs, il pourrait écouter.

Comment calculez-vous _x_ avec _x_ modulo cubique _n_ et _p_ et _q_?

@Justin: version courte: vous calculez _d_, l'inverse de 3 modulo _phi (n) _ où _phi (n) = (p-1) (q-1) _. Ensuite, vous effectuez une exponentiation modulaire de _x ³ _ modulo _n_, avec _d_ comme exposant. Il y a des explications raisonnablement claires sur la [page Wikipedia sur RSA] (http://en.wikipedia.org/wiki/RSA_%28algorithm%29).

C'est une excellente réponse complète!

Serait-il vrai de dire que n n'a que 4 facteurs: 1, p, q et n?

Si _p_ et _q_ sont deux entiers premiers distincts et _n = pq_, alors il y a exactement quatre entiers positifs qui divisent _n_, et ce sont _1_, _p_, _q_ et _n_ lui-même. Les valeurs _1_ et _n_ sont souvent dites "diviseurs triviaux" tandis que _p_ et _q_ sont difficiles à calculer. Strictement parlant, seuls _p_ et _q_ sont appelés "facteurs", c'est pourquoi "diviseur" serait une terminologie plus exacte ici.

Je suppose qu'après avoir lu tout cela, je ne comprends pas comment un attaquant n'a pas pu regarder l'ordinateur auquel il tente d'accéder pour générer la clé qui est envoyée à l'autre partie pour démarrer la connexion sécurisée.

@greg: Comment pouvez-vous regarder cet ordinateur faire des choses, à moins que vous n'y ayez déjà accès? (Réponse: Heartbleed)

Si l'attaquant regarde l'ordinateur lui-même de l'intérieur, l'échange de clé publique est inutile.Il protège uniquement contre quelqu'un qui observe la communication, pas quelqu'un qui surveille l'état interne du serveur lui-même.

gowenfawr

2011-08-16 00:17:48 UTC

view on stackexchange narkive permalink

Voici une version vraiment simplifiée:

Lorsqu'un client et un serveur négocient HTTPS, le serveur envoie sa clé publique au client.
Le client crypte le cryptage de la session clé qu'il souhaite utiliser en utilisant la clé publique du serveur, et envoie ces données chiffrées au serveur.
Le serveur déchiffre cette clé de chiffrement de session à l'aide de sa clé privée et commence à l'utiliser.
La session est maintenant protégée, car seuls le client et le serveur peuvent connaître la clé de cryptage de la session. Il n'a jamais été transmis en clair, ou de quelque manière qu'un attaquant puisse le déchiffrer, donc ils seuls le savent.

Voilà , tout le monde peut voir la clé publique, mais cela ne leur permet pas de décrypter le paquet "hé-allons-chiffrer-en utilisant-ce-à-partir-de-maintenant" qui est chiffré avec cette clé publique. Seul le serveur peut déchiffrer cela, car seul le serveur possède cette clé privée. Les attaquants pourraient essayer de forger la réponse contenant une clé chiffrée, mais si le serveur configure la session avec cela, le vrai client ne la parlera pas car ce n'est pas la clé que le vrai client a définie.

C'est toute la magie du cryptage à clé asymétrique. Des trucs fascinants.

P.S. «vraiment simplifié» signifie «des détails mutilés pour faciliter la compréhension». Wikipedia "Transport Layer Security" donne une réponse plus correcte en termes de détails techniques, mais je visais "facile à grok".

À ce stade, il est important de mentionner que la clé publique est [signée] (http://en.wikipedia.org/wiki/Digital_signature) par une autorité de confiance, c'est-à-dire même si l'attaquant est un [homme au milieu] (http : //en.wikipedia.org/wiki/Man-in-the-middle_attack), il ne peut pas prétendre être le serveur pour tenter de tromper le client pour qu'il crypte la clé partagée en utilisant * la clé publique de l'attaquant * à la place.

que se passerait-il si nous n'avions pas inventé le cryptage asymétrique?

Sans cryptage asymétrique, Internet tel que nous le connaissons n'existerait pas, point final. Vous ne pouvez pas vendre des choses à des systèmes clients aléatoires avec un cryptage symétrique. Internet serait comme la télévision, où vous regardez l'infopublicité, mais vous devez appeler au téléphone pour effectuer l'achat. Le cryptage asymétrique est vraiment * vraiment * ** un truc fascinant **

Viola? Don't you mean Voila? :)

Je suis désolé, le truc alto-voila est un truc tellement réflexif dans la blague avec moi, je l'ai utilisé sans y penser, et bien sûr, personne ici ne pouvait s'attendre à être dans cette blague. Donc, oui, voila était le contenu sémantique prévu, et alto n'était pas une faute de frappe mais une blague syntaxique obscure. Désolé pour ça.

gowenfawr - +1 Merci beaucoup pour votre réponse. J'avais entendu parler du cryptage asymétrique mais je l'avais oublié en réfléchissant à cette question. Votre réponse était très facile à comprendre. J'ai cependant accepté la réponse de Thomas Pornin parce que je sentais qu'il expliquait vraiment le mécanisme en profondeur.

@gowenfawr oui c'est l'une des choses les plus fascinantes, je l'ai appris sur https://www.coursera.org/course/crypto et depuis, je me suis de plus en plus intéressé à la cryptographie et aux bitcoins.

@gowenfawr Merci pour cette réponse simplifiée! Je suis convaincu que c'est ainsi que cela fonctionne depuis un certain temps maintenant, mais puisque tout le monde veut fournir des détails sur chaque couche du modèle OSI, il est impossible de trouver une validation de ma compréhension.

mais si nous utilisons un cryptage asymétrique, pourquoi est-il important que «seuls le client et le serveur puissent connaître la clé de cryptage de session (publique?)»?si la communication ne peut pas être déchiffrée à l'aide de la clé publique mais uniquement de sa clé privée correspondante, pourquoi la clé publique ne peut-elle pas être envoyée de manière non sécurisée?

@amphibient, car la clé de session est une clé de chiffrement symétrique utilisée pour chiffrer les données réelles.Les clés asymétriques ne sont utiles que pour crypter de petites quantités de données (comme K à un chiffre).Ainsi, le cryptage asymétrique basé sur la clé publique est utilisé pour échanger en toute sécurité une petite clé secrète qui est ensuite utilisée pour le cryptage symétrique de données à volume élevé.

merci, cela a du sens.cependant, [cette réponse populaire] (http://security.stackexchange.com/a/8309/20014) n'est-elle pas basée sur une hypothèse différente, à savoir que l'échange de données après la prise de contact suit également un cryptage asymétrique et non symétrique, comme vousdire?

@amphibient La réponse à laquelle vous avez lié semble omettre un détail très important: après l'échange initial qui sert à établir la clé secrète partagée, le serveur et le client passent au cryptage symétrique à l'aide de cette clé secrète.Ceci est fait pour plusieurs raisons différentes, dont la performance n'est pas la moindre: avec des longueurs de clé qui offrent une sécurité raisonnable, le chiffrement asymétrique est très lent, vous voulez donc minimiser la quantité de trafic que vous chiffrez en l'utilisant.Le cryptage symétrique, en revanche, peut être extrêmement rapide mais sécurisé.

+1 Pour "Je visais des groks faciles".

evil otto

2011-08-16 08:39:30 UTC

view on stackexchange narkive permalink

Les autres réponses sont bonnes, mais voici une analogie physique qui peut être plus facile à saisir:

Imaginez une boîte de verrouillage, du genre avec un rabat en métal sur lequel vous mettez un cadenas pour sécuriser. Imaginez que la boucle où vous placez le cadenas soit suffisamment large pour accueillir deux cadenas. Pour échanger en toute sécurité, envoyer quelque chose à une autre partie sans partager les clés de cadenas, vous

mettre le "Chose" dans la boîte et le verrouiller avec votre cadenas.
envoyer le boîte verrouillée à l'autre partie.
ils mettent également leur cadenas sur la boucle (de sorte qu'il y ait deux verrous dessus), et vous rendent la boîte à double verrouillage
Vous retirez votre cadenas et renvoyez-leur la boîte désormais verrouillée individuellement
ils retirent leur propre cadenas et ouvrent la boîte.

Avec le cryptage, les serrures et les clés sont mathématiques , mais le concept général est vaguement comme celui-ci.

C'est ainsi que j'allais l'expliquer aussi. La seule autre chose à ajouter est que ce complexe * va-et-vient * n'est nécessaire qu'une seule fois, car la `chose` que vous passez avec elle est une * clé partagée *. De cette façon, jusqu'à la fin de la * session *, les deux extrémités peuvent ouvrir la boîte de verrouillage et y mettre des choses. Chaque session a un nouveau cadenas et une paire de clés, vous n'avez donc qu'à les jeter à la fin de votre session. * 8 pi)

Un peu comme l'a dit @Mark Booth, à l'intérieur de la boîte se trouve un troisième cadenas avec un jeu de clés, et il sera utilisé pour tous les échanges futurs pendant la session.

De plus: la boîte et les cadenas sont en métal extrêmement dur. Il est absolument impossible de les ouvrir. Il est également sans danger contre les rayons X. Vous pouvez utiliser une bombe nucléaire pour évaporer la boîte et son contenu et il est parti, mais vous ne pouvez pas l'ouvrir.

J'ai toujours aimé cette explication. Beaucoup plus facile à comprendre qu'un tas d'équations mathématiques.

Une chose qui manque ici est l'authentification. c'est-à-dire qu'au lieu de véritables «ils» ont mis le deuxième verrou à l'étape 3, quelqu'un d'autre pourrait mettre le second verrou.

J'aime les images :) Le cryptage asymétrique ne serait-il pas plus comme ça: le serveur envoie une boîte vide et son cadenas à encliqueter ouvert sans clé, le client met un cadenas avec une clé (garde la deuxième clé), enclenche le cadenas du serveur, envoie la boîte?

@tanius, pas tout à fait.Le client récupère le cadenas ouvert du serveur, génère un code de verrouillage à combinaison, qu'il écrit et met dans la boîte, puis verrouille la boîte avec le cadenas du serveur.Le serveur ouvre son propre cadenas avec la clé correspondante, puis écrit le code combo à utiliser pendant la session.À partir de là, ils n'utilisent plus que des serrures à combinaison.(clé symétrique).En fait, je pourrais dire la même chose que vous, pas sûr.

Je ne peux pas comprendre comment l'analogie représente la cryptographie à clé publique.Quelqu'un peut-il expliquer

Cette analogie physique représente le protocole à trois passes, et qui est quelque peu différent de ce que les autres réponses contiennent, donc elle ne peut pas être utilisée comme analogie pour ces réponses, c'est différent, je demande à l'affiche d'ajouter cette note.

NDF1

2013-10-23 03:57:52 UTC

view on stackexchange narkive permalink

De nombreuses réponses déjà fournies négligent la capacité d'interception du FAI ou de la NSA. Jetez un œil à la Salle 641A du centre de données AT&T. On estime que 10 à 20 installations de ce type ont été installées aux États-Unis. Jetez également un œil au bâtiment One Wilshire, où 260 connexions de FAI convergent en un seul bâtiment. Cet emplacement est un emplacement privilégié pour une installation d'interception.

Le fait est qu'un FAI (ou l'équipement installé par la NSA dans le FAI) peut intercepter et MITM attaquer une connexion SSL et ils peuvent le faire assez facilement en fait.

Votre navigateur Web ou système d'exploitation contient plus de 500 certificats de confiance installés. Cela signifie que vous faites implicitement confiance à tout site Web dont le certificat a été signé par ce certificat.
La NSA via une décision secrète du tribunal FISA peut forcer toute autorité de certification opérant aux États-Unis à donner leur leur certificat racine. L'ordonnance du tribunal comprend une clause spéciale de non-divulgation qui oblige le CA à se taire sous peine d'emprisonnement s'il en parle. Ils n’ont peut-être même pas besoin de le faire, mais il leur suffit de convaincre les fournisseurs de navigateurs d’accepter un certificat appartenant à la NSA comme étant approuvé dans le navigateur.
Lorsque votre trafic passe par le Le FAI échange la véritable clé publique du site Web avec la propre clé publique de la NSA signée par l'autorité de certification compromise, effectuant ainsi l'attaque MITM.
Votre navigateur Web accepte ce faux certificat comme étant de confiance et vous communiquez la clé de chiffrement symétrique pour l'échange vers le NSA / FAI qui en garde une copie et transmet également la même clé sur le site Web.
Votre session avec le site Web est déchiffrée en temps réel avec la clé symétrique compromise.
Les données déchiffrées sont envoyées via une ligne de fibre optique au siège et centre de données de la NSA dans le sous-sol de Fort Meade. Cela analyse les données pour des centaines ou des milliers de mots-clés qui peuvent indiquer différents types de menaces. Tous les mots-clés sont signalés par un indicateur rouge pour qu'un analyste puisse afficher et prioriser les actions supplémentaires le cas échéant. Les données finales sont envoyées à l'une des installations de stockage de données de la NSA aux États-Unis. La nouvelle installation de stockage est le centre de données de l'Utah, qui est probablement déjà en ligne car il devait être en ligne à la fin du mois dernier.

Voici un diagramme de nsawatch .org:

the NSA surveillance octopus

Ne forceraient-ils pas simplement l'exploitant du site Web à remettre leur propre certificat, ce qui rendrait le tout complètement transparent. Si la NSA doit créer de nouveaux certificats pour chaque site Web, le suivi des empreintes digitales des certificats révélera l'écoute clandestine. Par exemple, si l'empreinte digitale de la clé SSL de mon entreprise diffère entre le moment où j'accède au site Web au travail et le moment où j'y accède à la maison, je saurai que le certificat a été compromis. De même, s'ils n'utilisent que ma connexion Internet domestique, je peux rechercher des modifications d'empreinte digitale qui diffèrent entre le réseau domestique et un autre réseau.

@Johnny: qui fonctionnerait quelque peu, mais la paresse des utilisateurs pour vérifier les signatures de cert pour chaque site sécurisé qu'ils visitent se produirait le plus souvent. En outre, certains sites HTTPS changent les certificats selon un calendrier (disons tous les 6 mois), ce qui rend difficile de dire si un changement de signature de certificat est effectivement valide.

@Johnny Une grande partie d'Internet a également utilisé le bogue d'interchangeabilité transparente de l'autorité de certification racine * comme fonctionnalité *. Naviguer sur Internet moderne avec des outils comme [Certificate Patrol] (https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/) est un cauchemar d'échanges et de commutateurs «légitimes» qu'une agence d'espionnage change pourrait se cacher à l'intérieur, comme une aiguille dans une botte de foin. J'ai renoncé à utiliser Cert Patorl pour cette raison. La norme * v3 X.509 * sous-jacente est cassée.

@suriv Ce n'est pas une affirmation douteuse, c'est un fait. Consultez les [National Security Letters] (https://en.wikipedia.org/wiki/National_security_letter) ou le [Foreign Intelligence Surveillance Act] (https://en.wikipedia.org/wiki/United_States_Foreign_Intelligence_Surveillance_Court#Secret_law).

@NDF1 aucun de ces articles ne soutient en aucune façon votre affirmation. En fait, ils le contredisent: "Selon la loi, les NSL ne peuvent demander que des informations non liées au contenu, par exemple des enregistrements transactionnels et des numéros de téléphone composés"

[Faites des recherches vous-même] (https://nakedsecurity.sophos.com/2014/01/29/lavabit-appeals-contempt-of-court-ruling-surrounding-handover-of-ssl-keys/). Voir aussi [Lois sur la divulgation des clés] (https://en.wikipedia.org/wiki/Key_disclosure_law). Elles peuvent contraindre une entreprise ou un individu à remettre une clé SSL via une décision judiciaire. La FISA traite des ordonnances judiciaires secrètes, donc si elles sont liées à la sécurité nationale, elles ne verront jamais le jour. S'il est dans l'intérêt de la sécurité nationale de forcer une autorité de certification à remettre son certificat de signature racine, elle le fera. Bien sûr, les CA américains sont tous vulnérables à cela.

Hendrik Brummermann

2011-08-16 00:32:12 UTC

view on stackexchange narkive permalink

En termes simples: il y a deux cryptages différents en cours:

Il y a d'abord le cryptage à clé publique / privée . Le client utilise la clé publique du serveur (qui est incluse dans le certificat) pour crypter certaines informations que seul le serveur peut décrypter en utilisant sa clé privée.
Sur la base de ces informations une clé de session est dérivée, qui n'est connue que du serveur et du client. Cette clé de session est utilisée pour crypter ces données.

Ceci est un résumé très approximatif.

Il y a beaucoup plus de choses à faire pour empêcher divers types d'attaque:

Par exemple, le client essaie de valider le certificat du serveur pour s'assurer qu'il ne parle pas à un homme au milieu.
Il existe différents algorithmes et les longueurs de clé pour les clés de session qui doivent être négociées
Les nombres aléatoires qui ne sont utilisés qu'une seule fois sont utilisés pour empêcher les attaques de relecture.
Le protocole d'échange de clés Diffie-Hellman peut être utilisé pour générer une clé de session qui ne peut pas être reconstruite par une personne qui a enregistré la transmission de données cryptées et a accès à la clé privée du serveur à un plus tard ( Perfect forward secrecy).
...

Jeff Ferland

2011-08-16 00:55:07 UTC

view on stackexchange narkive permalink

Je pense aux six réponses déjà disponibles, celle de gowenfawr l'explique le mieux. Lisez-le d'abord car il ne s'agit que d'un addendum.

Sur Diffie-Hellman

Plusieurs réponses mentionnent les échanges Diffie-Helman. Celles-ci sont mises en œuvre dans une minorité d'échanges. Un échange DH est signé par la clé du serveur pour empêcher une attaque MITM. Étant donné que la clé n'est pas chiffrée sur une clé publique, elle ne peut pas être récupérée à l'aide d'une clé privée capturée contre le trafic capturé d'un échange de clés. C'est l'idée du Perfect Foward Secrecy. OpenSSL permet à la fois les échanges de clés "ordinaires" et DH selon la configuration.

Sur les chaînes MITM / Signature

Les échanges de clés publiques et DH empêchent quelqu'un d'observer la connexion et de dériver la clé. Ceci est basé sur tout un tas de problèmes mathématiques que vous pouvez rechercher / regarder la réponse de Thomas pour comprendre. Le problème avec l'un ou l'autre est l'attaque MITM. Pour la cryptographie à clé publique, cela est résolu soit en connaissant la clé publique au préalable (même si l'échange est observé), soit au moyen d'une chaîne de certificats. Exemples: je fais confiance à Alice et Alice a signé la clé de Bob certifiant qu'elle est bien la sienne. Aussi connu sous le nom de Google, il est certifié par ... euh, Google. Il semble qu'ils soient dans Firefox en tant que leur propre autorité de certification. Ainsi, random_bank's_ssl est signé par Verisign, et mon navigateur fait confiance à Verisign pour émettre uniquement des certificats légitimes.

Des problèmes existent avec ce modèle lorsque vous rencontrez des choses comme une autorité de certification compromise. Dans ce cas, une attaque MITM devient possible.

apsillers

2013-10-23 02:06:14 UTC

view on stackexchange narkive permalink

SSL repose sur la cryptographie à clé publique. Un serveur qui participe à SSL a une paire de clés , qui a des composants publics et privés.

Imaginez que vous ayez un lockbox spécial avec deux clés: une clé peut verrouiller la boîte, et un autre peut déverrouiller la boîte. Si votre ami souhaite vous envoyer un message secret, il n'a besoin que de la clé de verrouillage et vous pouvez garder la clé de déverrouillage privée .

En fait, vous pouvez librement donner votre clé de verrouillage à tout le monde. Vous décidez de laisser de côté des copies de vos coffres spéciaux et des clés de verrouillage sur votre porche afin que tout le monde puisse en avoir une copie. Bientôt, tout le monde dans toute votre ville pourra vous envoyer des messages secrets par courrier. Vous avez défini votre clé de verrouillage publique^.

Si votre amie Alice veut vous envoyer un message secret, elle place son message dans une boîte à clé et le verrouille avec une copie de votre clé de verrouillage publique. Le maître de poste de votre ville se méfie beaucoup de vous et d'Alice, mais - même s'il a lui aussi accès à votre clé publique - il ne peut pas ouvrir le coffre. Seul vous, seul propriétaire de la clé de déverrouillage privée, pouvez ouvrir la boîte qu'Alice a verrouillée.

Ainsi, votre FAI (ici, le postmaster) a accès à votre clé publique , mais cela ne les aide pas à déchiffrer les messages chiffrés avec votre clé publique. Votre clé publique crypte uniquement, et seule votre clé privée décrypte. Ainsi, votre clé privée ne quitte jamais votre possession, donc personne n'y a accès sauf vous, et donc personne ne peut écouter vos messages.

Il y a un peu plus de protection que SSL vous donne (par exemple, supposons que le le postmaster jette la boîte d'Alice et vous envoie un nouveau message en prétendant être Alice), mais cela devrait clarifier pourquoi votre FAI ne peut pas simplement déchiffrer vos messages.

J'ai une question. nous chiffrons les données en utilisant un algorithme et les déchiffrons en utilisant le contraire de l'algorithme. donc si nous avons les données brutes et la clé publique, pourquoi ne pouvons-nous pas décrypter les données cryptées en utilisant le contraire de l'algorithme de cryptage?

Les systèmes à clé publique @AmirrezaNasiri sont basés sur des problèmes mathématiques extrêmement difficiles à exécuter en sens inverse. Voir le [problème de logarithme discret] (http://en.wikipedia.org/wiki/Discrete_logarithm) pour un tel problème: pour `a = b ^ k mod q`, il est trivial de calculer` a` si vous savez ` b »,« k »et« q ». Cependant, il est difficile de trouver «k», même si vous connaissez «a», «b» et «q». L'article de Wikipedia a un bon exemple et une bonne explication.

deadalnix

2011-08-16 00:24:21 UTC

view on stackexchange narkive permalink

Regardez Diffie Hellman: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Pour des raisons de performances, la connexion est chiffrée avec clé symétrique. Mais la clé symétrique est générée lors de l'établissement de la connexion et n'est jamais échangée en clair, mais en utilisant une cryptographie asymétrique.

La cryptographie asymétrique est une technique où deux clés sont nécessaires: une publique et une privée. Ce qui est crypté avec la clé publique doit être décrypté avec la clé privée et inversement. Ainsi, les deux ordinateurs peuvent échanger des données sur la base de leurs autres clés publiques. Mais seul le propriétaire de la clé privée correspondante peut la déchiffrer. La clé privée n'est jamais échangée, donc, même si vous avez tout reniflé, vous ne pouvez rien décrypter. Ces techniques sont coûteuses, elles sont donc utilisées pour échanger la clé contre la clé de cryptographie symétrique et non les données elles-mêmes.

Bien que Diffie Hellman puisse être utilisé et ait la belle propriété de transmettre le secret, il n'est normalement pas utilisé pour des raisons de performances.

@Hederik: Mais c'est le protocole de cryptographie le plus simple qui donne le secret dans un canal de communication que l'attaquant ne peut écouter.

scuzzy-delta

2013-10-23 01:30:12 UTC

view on stackexchange narkive permalink

La sécurité de la couche de transport (qui est ce que l'on appelle maintenant Secure Sockets Layer) implique des méthodes d'échange de clés cryptographiques en toute sécurité sur un canal de communication non sécurisé (comme Internet).

Oui, cela signifie que le FAI peut voir les informations d'échange de clés lors de leurs va-et-vient, mais n'a toujours pas suffisamment d'informations pour lire le flux de messages une fois qu'une connexion sécurisée a été établie.

Un concept très étrange, et c'est un travail assez nouveau. L'exemple le plus courant de ceci s'appelle Échange de clés Diffie-Hellman, et n'a été inventé que dans les années 1970.

L'article de Wikipédia contient tous les délicieux détails mathématiques, mais je trouve le l'image ci-dessous (de Wikimedia) illustre parfaitement le concept. Regardez-le, réfléchissez-y, essayez-le même par vous-même, et vous constaterez qu'il n'y a aucun moyen pour un adversaire de dériver la clé privée des informations visibles publiquement.

enter image description here

LateralFractal

2013-10-23 06:18:06 UTC

view on stackexchange narkive permalink

Si je mets mon chapeau noir (pas ce chapeau noir... en fait, ce chapeau fonctionne aussi):

Un FAI peut simplement effectuer un man-in-the -middle-attaque sur l'un de vos téléchargements HTTP d'applications ou de leurs correctifs et ainsi mettre à jour la chaîne de confiance du navigateur directement ou la mettre à jour indirectement avec un cheval de Troie autodestructeur.

Microsoft exige uniquement que les pilotes soient signés par code; les signatures numériques pour les applications et les données exécutables équivalentes aux applications ne sont pas appliquées par défaut *. La plupart des systèmes d'exploitation grand public ne sont pas meilleurs ne serait-ce que simplement parce que la signature du code d'application obligatoire (et la vérification d'identité) coûterait juste assez pour réduire considérablement la taille de leur écologie logicielle.

_{* Je mets un point d'honneur à ne pas créer de lien vers Microsoft Answers sauf si je suis obligé de le faire. Leurs singes dressés utilisent évidemment des machines à écrire cassées.}

Bonne suggestion là-bas. :RÉ

MITM-ing le processus de mise à jour est un excellent point ... mais il me semble que le FAI devrait compromettre la clé privée du serveur de mise à jour pour le faire (ce qui, je pense, empiète sur le territoire NSA / TLA). Avez-vous des incidents en tête?

@scuzzy-delta Les serveurs de mise à jour des grandes organisations sont probablement signés numériquement de manière vérifiée par le processus de correctif (jeux Blizzard par exemple); mais dans l'ensemble, la plupart des téléchargements initiaux ne sont pas limités au canal d'accès HTTPS et la plupart des mises à jour ne sont ni signées ni vérifiées par l'automatisation des correctifs si l'automatisation existe. En théorie, notre tout nouvel ordinateur OEM devrait être livré avec un support ROM des autorités de certification racine vérifiées par des auditeurs indépendants de l'OEM, et * tout * téléchargé par la suite en utilisant HTTPS ou un équivalent signé.

Zds

2011-08-16 00:21:58 UTC

view on stackexchange narkive permalink

L'élément clé ici est le cryptage asymétrique ou à clé publique. Cela signifie que vous avez deux éléments de clé, publique et privée, et une fonction mathématique qui est facile à calculer dans une direction mais très, très difficile à calculer dans l'autre.

Donc, quand les serveurs envoient son public key, nous pouvons utiliser la clé publique pour chiffrer facilement nos données, mais uniquement avec l'autre clé de la paire, clé privée dans ce cas, vous pouvez facilement la déchiffrer.

goodguys_activate

2011-09-21 05:34:23 UTC

view on stackexchange narkive permalink

La Conférence EcoParty a annoncé un outil appelé BEAST qui décrypterait le trafic SSL3 / TLS1.0 et moins, probablement en l'observant.

Voici un lien vers le rapport de nouvelles

Je suis sûr que dans les prochains jours, nous en saurons plus à ce sujet, les solutions de contournement et les limites.

Cette section ci-dessous sera mise à jour au fur et à mesure que de plus amples informations seront découvertes.

Ce hack suppose que l'attaquant peut d'une manière ou d'une autre voir votre trafic réseau; via un logiciel espion ou via une capture réseau. Les machines mal administrées et les utilisateurs Wifi sont les plus susceptibles d'être les suspects habituels… mais sans s'y limiter.

Il existe des rapports selon lesquels nous pouvons atténuer ce risque en modifiant la liste de chiffrement SSL * / TLS 1.0 à RC4, et ne prend pas en charge les anciennes combinaisons. Une autre atténuation consiste à augmenter la longueur du jeton d'authentification, ce qui ralentirait l'attaque. La modification de la configuration des cookies d'authentification d'appartenance à Siteminder et ASP.net peut être utile ici.

Juste pour que vous sachiez que cette vulnérabilité est exposée par les mêmes personnes qui ont annoncé le «Padding Attack on ASP.NET» l'année dernière. Ce vieux problème met en danger chaque serveur Web IIS simplement en étant activé, ce qui semble être plus grave que cette attaque.

Partagez les liens que vous trouvez qui mentionnent ou confirment ces scénarios vulnérables, ou atténuations ici. Dans l'état actuel des choses, cela relève en partie de la spéculation et n'est pas vérifié par des experts en cryptologie.

BEAST semble être une attaque contre HTTPS uniquement, mais cette faille semble être dans SSL3 / TLS1.0. Les autres applications qui utilisent SSL / TLS 1.0 sont-elles vulnérables à une attaque similaire non-JavaScript?

sahmeepee

2013-10-23 01:20:57 UTC

view on stackexchange narkive permalink

Non, ils ne détiendraient pas la clé car la connexion que vous établissez est entre vous et le site cible (par exemple Amazon), de sorte que le FAI n'aurait aucune connaissance de la clé.

Le plus général réponse à la question sur le fonctionnement de SSL / TLS ici.

WTH

2017-03-28 18:00:39 UTC

view on stackexchange narkive permalink

Encore une fois, si vous cherchez à être à l'abri du gouvernement ou des pirates - ce n'est pas assez. Si vous cherchez à empêcher votre FAI de consulter vos données, c'est probablement suffisant.

Bien que cela puisse être un conseil utile pour TLS en général, je ne suis pas sûr qu'il réponde réellement à la question spécifique posée ici.

C'est mieux que celui ci-dessus qui dit simplement "parce que 'magique'" ... C'est bizarre de voter contre parce que je n'ai pas pris la peine de copier toutes les autres réponses, mais je les ai plutôt ajoutées avec les choses qui sont réellement importantes dans SSL / TLS moderneConnexions.C'est pourquoi j'ai spécifiquement souligné que de nombreuses réponses sont bonnes et couvrent certaines des raisons pour lesquelles vous ne pouvez pas décrypter les données - puis je souligne qu'elles sont incomplètes.Je peux vous MITM avec ECDH / DH malgré ce que dit la réponse la mieux notée - parce que cette réponse est incomplète.Sans épinglage et sans magasin de confiance local sécurisé, vous n'êtes pas en sécurité.

Je ne dis pas que les informations que vous fournissez sont mauvaises ou erronées - ce n'est pas le cas.Je dis que cela ne répond pas à la question.Question: "Comment est-il possible que les personnes observant une connexion HTTPS en cours d'établissement ne sachent pas comment la déchiffrer?"Réponse: "Vous avez besoin d'un épinglage DH / ECDH et SSL."Ce n'est pas un match.

Vous avez sûrement alors décliné les réponses en commençant par: "Un grand nombre des réponses déjà fournies négligent la capacité d'interception du FAI" «Je pense aux six réponses déjà disponibles, c'est celle de gowenfawr qui l'explique le mieux. Lisez-la d'abord car il ne s'agit que d'un addendum. "Si je mets mon chapeau noir (pas ce chapeau noir ... en fait ce chapeau aussi" "L'élément clé est le cryptage asymétrique ou à clé publique" "La conférence EcoParty a annoncé un outil appelé BEAST" puis - parce qu'aucun d'eux ne répond non plus à la question.Ce n'est pas un gros problème, cela semble plutôt mesquin.Ce n'est pas à cela que sert DV.