ECDHE_RSA y gmail

Question

ECDHE_RSA y gmail

#1 de Thomas Pornin (3 votos)

5

Estoy usando Chrome en Ubuntu Linux para conectarme a Gmail. La información de conexión dice que ECDHE_RSA se usa para el intercambio de claves simétricas https.

Según mi comprensión de TLS y Gmail, mi cliente crea una clave simétrica, se cifra con la clave pública de Google incluida en su certificado y luego se envía a Google. Ya que mi navegador reconoce el certificado de Google, ¿es seguro asumir que mi conexión es segura y no puede ser comprometida por un hombre en el ataque central? ¿Cómo podría un hombre en el medio ver la clave simétrica ya que no tiene la clave privada de Google para descifrar el mensaje?

No tengo un certificado importado en mi navegador. Utilicé Wireshark para espiar la negociación TLS. Veo en mi paquete de "cliente hola" que envío información sobre qué conjuntos de cifrado admite mi cliente, un número aleatorio e información de curva elíptica. Después de que el servidor de gmail responde con un "servidor hola" y "certificado, intercambio de claves del servidor, servidor hola hecho", mi cliente envía "intercambio de claves del cliente, cambio de especificaciones de cifrado, mensaje cifrado de intercambio". ¿Es correcto suponer que la clave simétrica que está cifrada con la clave pública de Google está en este paquete bajo el "Mensaje de reconocimiento cifrado" (TLSv1.1 Record Record: Protocolo de protocolo de enlace: Mensaje cifrado de protocolo de enlace).

¿Hay alguna forma en que un servidor pueda tomar una huella digital (es decir, identificar de manera única) a mi cliente en una futura conexión TCP en una red diferente a través de la clave simétrica que mi cliente generó anteriormente?

encryption tls certificates man-in-the-middle x.509

pregunta Randall 07.03.2013 - 10:51

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption tls certificates man-in-the-middle x.509

¿Hay algún motivo malicioso para bloquear las CRL? Configuración de laboratorio en casa con Snort y Vyatta: busca recomendaciones o consejos sobre recursos

score 3 · Answer 1

Con ECDHE_RSA, el intercambio de claves real utiliza Elliptic Curve Diffie-Hellman ; la clave pública ECDH del servidor no está en su certificado, sino en el mensaje ServerKeyExchange , que el servidor firma con su clave privada (y su navegador verifica esa firma en relación con la clave pública que está en el certificado del servidor). La clave simétrica que resulta de ECDH no es "elegida" solo por el cliente, pero sigue siendo una clave compartida por el cliente y el servidor, y ninguna otra. Eso es menos directo que su descripción, pero su idea es correcta: de hecho, siempre que la implementación sea correcta y su navegador valide correctamente el certificado del servidor, los datos intercambiados estarán a salvo de intrusos, suplantaciones y alteraciones maliciosas.

Si su cliente intenta volver a conectarse al mismo servidor (esto es normal en un contexto web, ya que los servidores tienden a interrumpir las conexiones después de 15 segundos de inactividad), intentará reutilizar la clave simétrica de ECDH, para evitar Todo el negocio de la criptografía asimétrica y, lo que es más importante, evitar una red de ida y vuelta. Este es el apretón de manos abreviado de SSL / TLS . Si tanto el cliente como el servidor aún recuerdan la conexión anterior (llamada "la sesión SSL"), esto funcionará. En estas condiciones , el servidor podría reconocer que el cliente es "el mismo que anteriormente".

Sin embargo, los parámetros de sesión SSL (la clave simétrica negociada) no se almacenan en un área de almacenamiento permanente y están sujetos a olvidos. Si cierras tu navegador, olvidará todas esas sesiones. Un servidor Apache recordará, de manera predeterminada, los parámetros de sesión SSL para 5 minutos , o posiblemente menos si maneja muchas conexiones (ya que su espacio de almacenamiento para dichos parámetros tiene un tamaño configurable pero finito).

Consulte esta respuesta para obtener una descripción detallada de la Protocolo SSL.