Diffie-Hellman en lugar de SSL?

Question

¿Se puede usar un algoritmo de intercambio de claves Diffie-Hellman para encriptar la comunicación cliente-servidor en una página web en lugar de SSL? Si puede, ¿cuáles son las desventajas (es decir, por qué el estándar usa SSL que requiere una autoridad de certificación)? Tengo entendido que Diffie-Hellman se puede usar para establecer secretamente una clave compartida que luego se puede utilizar para encriptar cualquier comunicación adicional.

Answer 1

Actualmente Diffie-Hellman es parte de SSL. Pero una parte no reemplaza a otras.

De here SSL Diffie-Hellman se utiliza para:

Esta un intercambio de claves Diffie-Hellman en qué certificado del servidor contiene los públicos parámetros Diffie-Hellman firmados por la autoridad de certificación (CA) Es decir, el certificado de clave pública contiene los parámetros de clave pública Diffie-Hellman. El cliente proporciona sus parámetros de clave pública Diffie-Hellman en un certificado , si se requiere autenticación de cliente , o en un mensaje de intercambio de clave . Este método da como resultado una clave secreta fija entre dos pares, según el cálculo de Diffie-Hellman utilizando las claves públicas fijas .

Answer 2

Los dos no son realmente comparables. DH es un algoritmo de intercambio de claves, nada más y nada menos. SSL intenta establecer que el servidor al que se está conectando es realmente quien dice que es. Para hacer eso, usa un certificado que se puede remontar a alguien en quien se supone que se puede confiar.

DH, por sí solo, solo impide que otros lean los datos transmitidos. SSL pretende establecer mucho más que eso (pero puede usar DH para evitar que otros lean la transmisión).

Solo por un ejemplo obvio, usar DH (solo) un ataque de Hombre en el medio es bastante simple. Si puedo lograr que te conectes a mi servidor en lugar del que pretendías, puedo usar DH para establecer una sesión "segura" contigo. Luego me conecto al servidor que originalmente pretendías. Cada paquete que recibo de ti, lo desencripto, lo vuelvo a cifrar con una clave que utilicé para conectarme a ese servidor y lo envío a ese servidor. Hago lo mismo con todos sus paquetes de respuesta. Para usted, todo parece que vino directamente del servidor original, y la compra que realizó (por ejemplo) funciona como siempre. Lo único que cambia es que también guardo el número de su tarjeta de crédito, y cuando intenta llenar su automóvil con combustible al día siguiente, el cargo se rechaza porque, mientras tanto, he gastado todo su crédito.

La autenticación en SSL está pensada al menos para evitar que eso suceda. Si su navegador intentó conectarse a (por ejemplo) www.amazon.com, debería darle una advertencia si mi certificado SSL no especifica que fue emitido a www.amazon.com, y una CA no debería emitir tal certificado a cualquiera pero Amazon.

Editar: Volviendo a leer esto, debería agregar un punto más: DH, por sí solo, realmente no garantiza ni la mayoría de lo que he dicho anteriormente. Por sí mismo, DH es solo una forma de intercambiar una clave (o, quizás podría decirse que es "intercambio de información necesaria para que ambas partes creen claves idénticas, sin cambiar la clave en claro"). Después de que ambas partes tengan la clave, pueden (y presumiblemente lo harán) usarla para encriptar/descifrar datos, pero esa encriptación está realmente separada de DH.

Answer 3

Puede usar el acuerdo anónimo de clave Diffie-Hellman con SSL. Esto proporciona privacidad en el canal, pero no autenticación.

Por supuesto, sin autenticación, realmente no puede tener privacidad, porque su canal privado podría estar conectado a un "hombre en el medio". Es por eso que se desaconsejan las suites anónimas de cifrado DH.

Si la falta de un certificado le impide el uso de SSL, donde es realmente necesario, conseguir libre de startcom.org.

Answer 4

Diffie-Hellman de intercambio de claves es solamente para keyexchange. No le da autenticidad (con quién está hablando), necesita certificados y una PKI para eso.

Así que sí se puede hacer cifrado, pero usted no sabe con quién está hablando a

Answer 5

El intercambio de claves DH no puede, por sí misma, cifrado. Se usa para establecer una clave de sesión, pero no para hacer la encriptación. Entonces, en este nivel, la pregunta es incorrecta o revela falta de precisión o falta de comprensión (sospecho que esta vez el problema es la precisión).

La pregunta es:

• ¿Quieres cifrar los datos con nadie en absoluto?
• ¿Quieres estar seguro de con quién estás hablando?

Como ya se señaló, SSL usa un intercambio de claves DH para establecer una clave de sesión. Sin embargo, también asegura que el programa en el otro extremo sea alguien en quien confíe (directa o indirectamente). Si no necesita preocuparse acerca de si la otra persona es confiable, puede simplemente usar un simple intercambio de claves DH y luego enviar datos encriptados sin necesidad de certificados. Pero no estará seguro de con quién está hablando a menos que valide eso, y los certificados utilizados por SSL, etc., ayudan con esa validación.