L'échange de clés Diffie-Hellman en place de SSL?

Peut faire un échange de clés de Diffie-Hellman algorithme utilisé pour chiffrer les communications client-serveur sur une page web à la place de SSL? Si cela est possible, quels sont les inconvénients (c'est à dire pourquoi la norme de l'utilisation de SSL qui exige un certificat de l'autorité)? Ma compréhension est que l'échange de clés Diffie-Hellman peut être utilisé pour secrètement établir une clé partagée qui peut alors être utilisé pour chiffrer les communications.

OriginalL'auteur kmnan | 2009-10-27

  1. 21

    Les deux ne sont pas vraiment comparables. DH est une clé de l'algorithme d'échange, rien de plus et rien de moins. SSL tentatives pour établir que le serveur auquel vous êtes connecté est vraiment qui il dit qu'il est. Pour ce faire, il utilise un certificat qui peut être tracée de nouveau à quelqu'un de vous (êtes censé être capable de) confiance.

    DH, par lui-même, ne conserve que les autres de lire les données transmises. SSL est destiné à établir beaucoup plus que ça (mais peut utiliser DH pour empêcher les autres de lire le flux de données).

    Juste pour un exemple évident, à l'aide de DH (par lui-même), un Homme au milieu attaque est assez simple. Si je me permet de vous connecter à mon serveur à la place de celui que vous souhaitez, je peux utiliser DH pour établir un "secure" session avec vous. J'ai ensuite se connecter au serveur à l'origine prévu pour. Chaque paquet que je reçois de vous, je vous le déchiffrer, re-crypter avec une clé que j'ai utilisé pour se connecter à ce serveur, et de les envoyer sur le serveur. Je fais la même chose avec tous ses paquets de réponse. Pour vous, tout semble comme il est venu directement à partir du serveur d'origine, et l'achat que vous avez fait (par exemple) fonctionne comme normal. La seule chose qui change, c'est que j'ai également stocker votre numéro de carte de crédit, et lorsque vous essayez de remplir votre voiture avec de l'essence de la prochaine journée, le débit est diminué, car dans l'intervalle, j'ai dépensé tout votre crédit.

    L'authentification SSL est au moins prévu pour empêcher que cela se produise. Si votre navigateur a essayé de se connecter (par exemple) http://www.amazon.com il devrait vous donner un avertissement si mon certificat SSL n'est pas préciser qu'il a été délivré à http://www.amazon.com -- et CA ne devrait pas délivrer un tel certificat à personne mais Amazon.

    Edit: en Relisant cela, je devrais ajouter un point de plus: DH, par lui-même, n'a pas vraiment de garantit même plus de ce que j'ai dit ci-dessus. Par lui-même, DH est simplement un moyen d'échange de clé (ou, peut-être il pourrait être libellée comme "échanger de l'information nécessaire pour les deux parties pour créer des clés identiques, sans jamais l'échange de la clé elle-même en clair"). Après que les deux parties ont la clé, ils peuvent (et sans doute va l'utiliser pour chiffrer/déchiffrer les données, mais que le chiffrement est réellement distinct de DH.

    OriginalL'auteur Jerry Coffin

  2. 9

    Fait l'échange de clés Diffie-Hellman est une partie de SSL.
    Mais une partie ne remplace pas les autres.

    De ici SSL échange de clés Diffie-Helman est utilisé pour:

    Ce un échange de clés de Diffie-Hellman dans
    qui le certificat du serveur
    contient de l'échange de clés Diffie-Hellman public
    paramètres signé par le certificat
    autorité de certification (CA). Qui est, le
    certificat de clé publique contient l'
    L'échange de clés Diffie-Hellman public-paramètres clés.
    Le client fournit à ses Diffie-Hellman
    public paramètres clés, soit dans un
    certificat, si l'authentification du client
    est nécessaire, ou dans un échange de clé
    message. Cette méthode aboutit à un
    fixe la clé secrète entre deux pairs,
    basé sur l'échange de clés Diffie-Hellman
    calcul à l'aide du public fixe
    les touches.

    Donc je suppose qu'il n'existe aucun moyen d'éviter l'utilisation de l'ICP. Je me demandais juste par curiosité si il y avait un moyen pour les 2 parties (indépendamment de l'algorithme de frais généraux) fiable pour établir un lien crypté sans l'utilisation d'une 3ème partie.
    En théorie non. Car, sans l'utilisation de tiers, vous ne pouvez pas être sûr que vous êtes l'établissement de lien crypté avec votre cible souhaitée.
    Bien sûr, il y est. Par exemple, si les deux parties d'échanger leurs clés publiques au cours d'une clé de signature de partie, alors ils n'ont pas besoin d'un 3ème partie pour établir une connexion sécurisée.
    Plus généralement, un canal sécurisé ne peut pas être établie entièrement en bande. Si c'est un groupe d'échange de matériel de clé entre les parties, ou à l'extérieur de la bande de réception de tiers clés, vous avez besoin d'aide supplémentaire pour établir un lien sécurisé.

    OriginalL'auteur alexkr

  3. 4

    Vous pouvez utiliser anonyme de clés Diffie-Hellman accord avec le protocole SSL. Ceci fournit la vie privée sur le canal, mais pas d'authentification.

    Bien sûr, sans authentification, vous ne pouvez vraiment pas avoir de vie privée, parce que votre canal peut être connecté à un "man-in-the-middle". C'est pourquoi l'anonyme DH suites de chiffrement sont découragés.

    Si l'absence d'un certificat est l'arrêt de l'utilisation de SSL où c'est vraiment nécessaire, obtenez gratuitement un de startcom.org.

    +1 - Soigné lien, j'ai pu créer mon propre certs pour mon serveur à la maison... je ne le savais pas, il y avait de libre-certs que l'utilisation d'une autorité de certification qui est intégré dans le navigateur de sorte que les visiteurs n'ont pas d'ajouter une exception
    Je ne pense pas que IE soutient, malheureusement. Je n'ai pas revu ces derniers temps donc je ne sais pas si c'est encore le cas.
    Fait une vérification rapide sur startcom.org révèle qu'ils ne prennent en charge Internet explorer.
    De soutien, ou d'inclure leur certificat dans le jeu par défaut?

    OriginalL'auteur erickson

  4. 2

    Échange de clés de Diffie-Hellman est seulement pour keyexchange. Il ne vous donne pas authenticitation (à qui on parle), vous avez besoin de certificats et PKI.

    Donc, oui, vous pouvez faire de chiffrement, mais vous ne savez pas à qui vous vous adressez,

    OriginalL'auteur Henri

  5. 1

    La DH d'échange de clé ne peut pas, de lui-même, ne le chiffrement. Il est utilisé pour établir une clé de session, mais ne pas faire le chiffrement. Donc, à ce niveau, la question est mal indiqué ou s'il se révèle un manque de précision ou de manque de compréhension (je soupçonne que la précision est le problème cette fois-ci).

    La question est:

    • Voulez-vous chiffrer les données avec quelqu'un?
    • Voulez-vous être sûr de qui vous parlez?

    Comme l'a déjà souligné, le protocole SSL utilise un DH échange de clés pour établir une clé de session. Cependant, il s'assure également que le programme à l'autre extrémité est quelqu'un en qui vous avez confiance (directement ou indirectement). Si vous n'avez pas besoin de s'inquiéter de savoir si l'autre personne est digne de confiance, vous pouvez simplement utiliser un simple échange de clés DIFFIE-et puis envoyer des données chiffrées sans avoir besoin de certificats. Mais vous ne pouvez pas être sûr de qui vous parlez, sauf si vous les valider et les certificats utilisés par le protocole SSL, etc aide à la validation.

    OriginalL'auteur Jonathan Leffler