SSL puede detener a los MiTM ... pero a largo plazo, ¿puede realmente? [duplicar]

  

Después de un tiempo, la CA habrá firmado un par de miles más   Certificados que deberán ser sincronizados y descargados al   navegador / aplicación usándolos. Lo que realmente está deteniendo un MiTM de   ¿Interceptando eso?

El hecho de que el certificado del sitio web esté firmado es lo que impide un MITM.

Voy a demostrar mi punto con un ejemplo simple. No sé si eso es exactamente cómo funciona el moderno SSL / TLS. Pero la idea básica sigue siendo la misma.

Paso 1, el navegador de Bob

Bob tiene una clave pública de CA. La clave pública de CA es conocida y nunca cambia, por lo tanto, está integrada en el navegador / sistema operativo de Bob.

Paso 2, Alice configura SSL / TLS

Alice quiere hacer que su sitio web esté protegido. Alice crea un par de claves privadas / públicas y envía la clave pública a la CA. La CA agrupa la clave pública, el nombre de dominio y otra información de Alice en un solo paquete. Luego, la CA encripta ese paquete con la propia clave privada de la CA y lo envía a Alice.

Ahora Alice tiene un certificado firmado que contiene su clave pública, nombre de dominio y alguna otra información. El certificado está cifrado (firmado) con la clave privada de la CA. Se puede descifrar con la conocida clave pública de CA.

Este paso solo debe realizarse una vez.

Paso 3, Bob se conecta a Alice

Bob se conecta al sitio web de Alice. Alice le envía a Bob su certificado firmado. Bob obtiene el certificado firmado y lo descifra con la clave pública de CA que ya conoce. Ahora, Bob comprueba si el nombre de dominio dentro del certificado coincide con el que se está conectando. Una vez hecho esto, Bob confía en que tiene la clave pública de Alice y no se puede producir MITM.

(Suponiendo que el CA no es malo)

Paso 4, Scar intenta interceptar

Bob se conecta al sitio web de Alice de nuevo. Alice le envía a Bob su certificado firmado. Esta vez, Scar, que tiene el control de la red de Bob, está escuchando el flujo de comunicación. Aunque puede interceptar y descifrar el certificado de Alicia usando la conocida clave pública de CA, no puede modificar el certificado y volver a cifrarlo porque Scar no tiene la clave privada de la AC. Lo mejor que puede hacer es corromper el certificado, pero eso alertaría a Bob y la conexión se interrumpiría.

Durante la generación de certificados, la clave privada nunca se envía a través de la red. Una combinación de clave pública / privada es generada por la organización que tiene el servidor que necesita un certificado. La clave pública / CSR se envía a la CA (y se cifra de tal manera que no se puede modificar en la ruta) y la CA luego firma la clave pública en un certificado y devuelve ese certificado a la organización. La organización luego utiliza ese certificado como prueba de que son quienes dicen ser.

Incluso con el control completo de la red, la clave privada para el servidor y la clave privada para la CA nunca se divulgan, por lo que es imposible que el tercero produzca un certificado falso o que la tercera parte obtenga la CA para producir un certificado falso.

Según su comentario, parecería que tiene un malentendido completo de cómo funciona SSL. Su pregunta no tiene sentido en el contexto del cliente que se conecta al servidor. La CA no envía nada al navegador, nunca. El navegador viene con certificados públicos raíz para la CA preinstalada y confiable. Esa CA luego usa la clave privada que controlan que corresponde a ese certificado para firmar un número infinito de otros certificados.

Cuando el servidor al que te estás conectando proporciona un certificado, dicen "aquí está mi clave pública que puedes usar para hablar conmigo y solo yo puedo entenderlo. Mira, ha sido firmado por una CA en la que confías, así que realmente soy yo " No hay forma de que un atacante falsifique esto, ya que no tiene acceso a la clave privada de la CA y no puede firmar un certificado para hacerlo confiable.